Hello Mit! No, not really. My assumption is that, because Token Exchange is an add-on to OAuth flows, most implementers simply add this feature themselves.
Thank you for the great video. With the example that you used of an administrator needing to replicate an issue, couldn't you use the "on behalf of" method? I'm trying to avoid using the impersonate method because logging of activities becomes more difficult. My scenario is the exact same as your example. Any thoughts?
Is it OK for a public client to do the token exchange? (3:59 so in case of the example having the client do the token exchange instead of the API gateway). I have a use-case where I might want to implement this flow, but I'm not sure if I'm understanding it fully. The use case: I have a game and normally I allow my users to login using Authorization Code with PKCE. However this game is also on Steam, and when a user launches the game though Steam they get an unique token. Instead of showing the default login flow I want to exchange this Steam token for a token that my resource server understands. So what I have in mind is the following: the game client performs the token_exchange with the auth server, it puts the Steam token in the subject_token field, and use a custom URI in the subject_token_type field (so the auth server can determine that it's a Steam token). Is this the correct approach? TLDR: Can I do the token exchange from the client? Can I use a custom URI in the subject_token_type field?
Hi there! Please have a look at this example of the token exchange spec: datatracker.ietf.org/doc/html/rfc8693#section-2.3. To me it sounds very similar to what you are trying to do. The main idea is what you ask for, receive a token of an accepted issuer (Stream) and issue a token for your resource server. Alternatively, you could also look into using id_token_hint. Since you re already supporting authcode with PKCE, you could accept an id_token (basically a JWT) issued by Steam which would be just a small extension to the protocol you already support. I hope this helps!
Hi Jonas! To be honest, your question completely confused me. Until this moment is was cleat to me that token exchange is meant for one client exchanging token for another, different token. If clients change, and they are internal clients that work within an infrastructure, I would say yes. Otherwise, I have to say it depends on the use case and has to be documented well. Sorry that I do not have a better answer for you.
If Issuer_A generates an Access Token using secret_A and sends Access_Token_A to the client. Then client sends Access_Token_A to API_Gate_Way_B, how is API_Gate_Way_B supposed to validate Access_Token_A it doesn't have secret_A? If you let API_Gate_Way_B know secret_A you could create your own Access_Token_As.
Hi there! Thanks for watching my video and asking a question. Well, in most cases access_token are issued as JWT these days. That means, the signature can be verified and therefore the authenticity of the token. In addition introspection endpoints are usually available. Wherever Token Exchange is supported authorization servers usually are configured to only accept certain token issuers. It is usually not a blind "let's exchange any token for ours" scenario. Please let me know if this helps.
Thank you Sacscha for explaining this rarely used topic in such details, which hard to find a good content....
That's great explanation! No much information about this feature yet. This video is golden
Thanks for explaining it in simple and clear terms!
Wonderfully explained. Thanks 🙂
Thank you, Nisanth!
You are so great to share this
Thank you, Rodney!
Keep making great tutorials! bought you coffee!
Thank you very much, Evgenia! I really appreciate it!
13:54 a sight of relieve? 😊. Nice explaination
Sounds like it, true 🙂
Great explanation !
Are there any existing libraries which supports token exchange flow ?
Hello Mit! No, not really. My assumption is that, because Token Exchange is an add-on to OAuth flows, most implementers simply add this feature themselves.
Thank you for the great video. With the example that you used of an administrator needing to replicate an issue, couldn't you use the "on behalf of" method? I'm trying to avoid using the impersonate method because logging of activities becomes more difficult. My scenario is the exact same as your example. Any thoughts?
Very nice
Wow this really helped out, thanks man
Glad it helped!
Hi Sascha! Great video. Are there any API Gateways that come with token exchange mechanisms out of the box?
Hi Rafal! Unfortunately, I cannot really tell. You may have to check for the API GW of choice yourself. Thanks for watching the video!
Is it OK for a public client to do the token exchange? (3:59 so in case of the example having the client do the token exchange instead of the API gateway).
I have a use-case where I might want to implement this flow, but I'm not sure if I'm understanding it fully.
The use case: I have a game and normally I allow my users to login using Authorization Code with PKCE. However this game is also on Steam, and when a user launches the game though Steam they get an unique token. Instead of showing the default login flow I want to exchange this Steam token for a token that my resource server understands. So what I have in mind is the following: the game client performs the token_exchange with the auth server, it puts the Steam token in the subject_token field, and use a custom URI in the subject_token_type field (so the auth server can determine that it's a Steam token). Is this the correct approach?
TLDR: Can I do the token exchange from the client? Can I use a custom URI in the subject_token_type field?
Hi there! Please have a look at this example of the token exchange spec: datatracker.ietf.org/doc/html/rfc8693#section-2.3. To me it sounds very similar to what you are trying to do. The main idea is what you ask for, receive a token of an accepted issuer (Stream) and issue a token for your resource server.
Alternatively, you could also look into using id_token_hint. Since you re already supporting authcode with PKCE, you could accept an id_token (basically a JWT) issued by Steam which would be just a small extension to the protocol you already support. I hope this helps!
thanks
Hey, the Token Exchange Flow can also be used at one IdP to exchange a Token from one Client to another?
Hi Jonas! To be honest, your question completely confused me. Until this moment is was cleat to me that token exchange is meant for one client exchanging token for another, different token. If clients change, and they are internal clients that work within an infrastructure, I would say yes. Otherwise, I have to say it depends on the use case and has to be documented well. Sorry that I do not have a better answer for you.
All my token expiering i dont understand how do to find all tokens? Could u just enter Gmail and it find all your ernings?
Hi Swedish Diamonds. Please provide more details, otherwise I cannot really help. Thanks
If Issuer_A generates an Access Token using secret_A and sends Access_Token_A to the client.
Then client sends Access_Token_A to API_Gate_Way_B, how is API_Gate_Way_B supposed to validate Access_Token_A it doesn't have secret_A?
If you let API_Gate_Way_B know secret_A you could create your own Access_Token_As.
Hi there! Thanks for watching my video and asking a question. Well, in most cases access_token are issued as JWT these days. That means, the signature can be verified and therefore the authenticity of the token. In addition introspection endpoints are usually available.
Wherever Token Exchange is supported authorization servers usually are configured to only accept certain token issuers. It is usually not a blind "let's exchange any token for ours" scenario. Please let me know if this helps.
@@saschazegermannice answer. Thx