Is it possible to customize the JWT access token c...
# talk-kratos
c
Is it possible to customize the JWT access token claims when kratos + hydra are operating in that mode? There seems to be a way to add
ext
and top-level claims but I can't find any documentation about it.
c
@limited-photographer-61008 Thanks, but unless I misunderstand how this works, it's not really what I'm after. I guess the client can ask to include specific claims in the token, but I want to get the token values from the backend, not the frontend (client). I would like to store information about a user (userinfo) in kratos or hydra, then have that information be available in the JWT access token.
I know this is possible for EXTERNAL jwts, since there is a mapper function in kratos to map claims from an external JWT to the hydra-generated one.
l
acceptOAuth2ConsentRequest
would be called from your backend. Whatever you put in
acceptOAuth2ConsentRequest.session.access_token
, ends up in the JWT under the
ext
claim. You know the identity/user at that point, so you can call whatever other services you need to get the user data and add it to the access token.
c
From the backend? In the examples it is called from the frontend? https://github.com/ory/kratos-selfservice-ui-node/blob/ea0caf28c7d6785efbe4149943f49fef4589a8b3/src/routes/consent.ts#L104 . If you're using any kind of SPA to do this I'm not sure how it would work
l
No, that’s a backend express server. It requires an admin api with an API key.
c
So is this flow just not possible from an SPA? I was just looking for a similar call in the kratos-selfservice-ui-react-nextjs and couldn't find one.
l
Yes, I think the Hydra login and consent endpoints require a backend.
c
I am only seeing just now that the consent api is at the /admin/ subpath, thanks. What about cases where you're not doing OIDC login though (e.g. kratos native login). Is there a way to customize the JWT in that case?
l
I don’t think you get a JWT in those flows.
You just get a cookie (browser) or session token (native), which you use to lookup the identity
c
Wait not even if you set the JWT access token strategy?
l
The access token is only for OAuth.
c
I guess that makes sense. I assumed that an access token would be used to grant access to other APIs.
(other APIs within ORY)
l
The non-admin ones work with the session cookie/token.
c
@limited-photographer-61008 I'm sure I'm missing the forest through the trees here, but how does kratos/hydra work with APIs if for first-party login use-cases it doesn't issue access tokens? For instance i have an instance of kratos/hydra set up alongside a set of apis. I have an SPA that logs into kratos and calls those same APIs. All components are under the same domain, but the SPA needs an access token to access the (non-ory) APIs. Do we have to do authorization code flow here (redirect to kratos login screen) to get an access token?
l
You can send the session cookie in the requests, and the API servers can use the whoami endpoint to lookup the user to perform authZ.
c
Is that really the recommended flow? All our APIs are built with OAuth2 in mind (each api requires a scope, etc)...
l
OAuth is generally more for 3rd party access to your APIs. And scopes are just what the user has consented the 3rd party app may access, but not necessarily what the user is allowed to access: https://www.ory.sh/docs/oauth2-oidc/overview/oauth2-concepts#scopes-vs-permissions
So you could maybe support both? But assume, if it is first party access via the session cookie, then all scopes are granted?
c
Right and in the case we're talking about the "client" is the first-party SPA acting on behalf of the user who has logged in. In that case I don't think it's unreasonable to use scopes as a proxy for permissions. Maybe there is a way to exchange a session token for an access token in first-party scenarios. Can Kratos/Hydra do that or do I need Oathkeeper?
l
You can use Hydra to get access tokens, refresh tokens, id tokens
If the user had already logged in, then I think they would just be asked to re-enter their password to confirm their identity when going through the OAuth flow.