I have a public client which gets JWT access token. I need it to get another one (not refresh, but for some other purpose) and I need it to do it without a user interaction.
As a result, I am trying to figure out whether there is a standard OAuth flow where I can use (JWT) access token (issued in a previous OAuth flow) to be used to authenticate for another OAuth flow (I can't authentication with the client secret since it's a public client).
All the things which I found are not a perfect match.
It does allow to authenticate via JWT token. However, it requires a client to issue JWT token (signed by a certificate owned by the client) and it checks for the signature. As a result, I can't use JWT access token which was issued by the Authorization server for this purpose.
This one allows using JWT access token and get another JWT access token. So close, but no cigar. JWT access token is not used for authentication in this flow. As a result, you still need client id client secret to authenticate
- Token refresh
This one potentially can be used it. Just use the refresh token to get a new JWT access token. However, it feels hacky. (I may need to do this operation a lot, as a result, it feels like an abuse of token refresh mechanics. Also, my guess is it will gradually pollute DB with used refresh tokens (this is a tiny secondary concern, however, again this solution feels hacky).
Am I missing anything?
CodePudding user response：
Token Exchange is fit for your use case, the client authentication part is optional:
The supported methods of client authentication and whether or not to allow unauthenticated or unidentified clients are deployment decisions that are at the discretion of the authorization server.
so you can use it with your public client. The other options listed are not meant to be used in the way that you require.
CodePudding user response：
Why do you need to avoid "user interaction" for the second token request? I can understand the desire (less interruption, etc.) but what's the reason behind it?
A user-based OAuth flow is going to require authentication with user credentials. That leaves you password flow or authorization code flow.
Password means you need the user's credentials to send...which I'm assuming you don't (and shouldn't have)
Authorization Code means that you need to redirect the user's browser to the authorization server's authorization endpoint (i.e. at least the potential for "user interaction") because the credentials were entered there to create a valid session. If the session at the authorization server is still valid, redirecting to the authorization server for the second authorization shouldn't require the user to type or click anything. However, if the session has expired, they would need to re-enter their credentials.
Update:
Token Exchange, to me, doesn't make sense for your use-case. If you're "impersonating", then your second token has the same privileges as the first. If you're "delegating" your new token has a subset of the privileges of the first.
Delegation semantics are different than impersonation semantics, though the two are closely related. With delegation semantics, principal A still has its own identity separate from B, and it is explicitly understood that while B may have delegated some of its rights to A, any actions taken are being taken by A representing B. In a sense, A is an agent for B.
ref: https://datatracker.ietf.org/doc/html/rfc8693#section-1.1
You can't delegate privileges you don't have.