Retrieve access token on OIDC login

[trautonen]

I've set up Hydra - Kratos integration using the Kratos OIDC provider but I cannot figure how to retrieve the access tokens generated by Hydra. By looking at https://github.com/ory/kratos/blob/master/selfservice/strategy/oidc/strategy_login.go I can't see where the token goes so that it would be accessible by the user application. The Kratos session identity only includes password credentials and not OIDC.

Should I handle the login somehow different or is that just something that is not supported?

[vinckr]

Hello @trautonen

You can retrieve the OIDC / OAuth 2.0 access, refresh, and ID tokens issued for the identity by social sign-in providers using the Ory CLI, cURL, JavaScript, or Go. These tokens are issued only when the Identity signs up with a social sign-in provider or links a new social sign-in provider to their account.
Here are the commands to get the Identity details that include the social sign-in provider tokens:

Ory CLI

ory get identity "{identity.id}" --project "{project.id}" \  
 -i oidc --format yaml

cURL

curl --request GET -sL \  
 --header "Content-Type: application/json" \  
 --header "Authorization: Bearer {ORY_API_KEY}" \  
 'https://{project.slug}.projects.oryapis.com/admin/identities/<identity_id>?include_credential=oidc'

JavaScript

import { Configuration, IdentityApi } from "@ory/client"  
  
const identity = new IdentityApi(  
 new Configuration({  
 basePath: `https://${process.env.ORY_PROJECT_SLUG}.projects.oryapis.com`,  
 accessToken: process.env.ORY_API_KEY,  
 }),  
)  
  
export async function getTokens(identityId: string) {  
 return await identity  
 .getIdentity({ id: identityId, includeCredential: ["oidc"] })  
 .then(({ data }) => data)  
}

You get something back like this for example:

credentials:
  oidc:
    config:
      providers:
      - initial_access_token: gho_wSL06H8Osomething
        initial_id_token: ""
        initial_refresh_token: ""
        provider: github
        subject: "12345678"

Please note that this only returns the initial access/refresh token. There is a PR open to add functionality to get a new token on every login: #2428

For more details, you can refer to the documentation.

Let me know if that solved your problem please!

[trautonen]

The registration is not done by the OIDC provider. The registration is done using self service flow or admin APIs in Kratos. Hydra issues the token on login, but as noted in #2428 this does not seem to be possible at the moment.

[vinckr]

I see. If you can share any rough diagrams for your flow, that would help.
As far as I understand it:

1. User registers with username/pw
2. User or admin links the OIDC account in Hydra to the Kratos identity
3. User logs in using the OIDC integration
4. At this point you would like to get the access token to use in your application (for what purpose exactly? couldn't you call kratos/whoami to check the session?)

Did I get it right or is it something else?

[trautonen]

In the Hydra - Kratos integration Hydra acts only as a JWT issuer. It just uses the Kratos identities directly. So the flow is:

1. User is registered using self service flow with username/pw to Kratos
2. User logs in using OIDC provider configured as Hydra that is backed by the Kratos identities
3. User gets Kratos session as per normal Kratos logins

But in 3. I would like to get the JWT also as that would be used not only in the current APP but other APIs in the system too. Currently the Kratos - Hydra custom integration is pretty useless if you cannot access the issued JWTs in login.

I can call Kratos whoami with the session I get from the login, but because #2428 is not merged the session does not include the Hydra issued JWT in it.

[trautonen]

Of course it's debatable if JWT or coordinated session is better approach, but for massive scale session lookups become a bottleneck vs standalone JWTs.

[trautonen]

And as for our use case I now switched to non JWT approach and we rely on Kratos sessions only and the central whoami endpoint. Our use case is tens of millions of users with a lot of authorized requests per user. We'll see how far we can get with a CDN and cached whoami endpoint and hopefully #2428 is merged when we hit a scaling bottleneck. Or just add enough database resources and Kratos nodes to serve the whoami. :)