Support for OAuth 2.0 Token Exchange (RFC 8693)

[rockebee]

Hi, before coming to my specific use case, I do have a related general question: Is there or will there be support for the quite fresh RFC 8693 specification within AppAuth libraries? Basically this is specifying a new grant type for token endpoint which allows to exchange some subject-specific token with a complete (new) set of OAuth/OpenID tokens.

The OAuth 2.0 Token Exchange draft is already supported somewhat by a set of the larger OpenID Provider implementations, e. g. within Keycloak, within oidc-provider, within Auth0.com or soon within Connect2Id.

For my specific background: I'm currently working on an app project which is supposed to provide two different flows for finally signing in to an OpenID Connect based Authorization Server, depending on (1) whether an account already exists at the AS, or (2) when there is a multistep "account-creation-plus-purchase-flow" in between. Basically the first case is a regular Auth Code + PKCE flow for which I'd like to make use of the great AppAuth library. However, case (2) is a bit tricky in the sense that due to the more-than-pure-login flow there is no upfront known step on which the AS can/should trigger the redirect to custom scheme uri for switching back to app context. Additionally the webapp which is used within browser tab to handle the registration, purchase and configuration flow is in itself an OpenID client to the same AS, hence this is not any Authorization Code flow at all anymore from the viewpoint of the native Android app.

For (2) I'm now aiming to provide a custom user experience which basically looks like this:

1. The native app generates a random challenge app_verifier and a corresponding S256 hash of it (app_challenge) => obviously borrowed from PKCE
2. From native app, a browser or a Chrome Custom Tab is opened with app_challenge being part or URL query parameters
3. The SPA web app in browser starts its own Auth Code w/ PKCE flow towards the AS, adding the app_challenge as an extra param to the /authorization endpoint
4. The AS performs regular Authorization Code Flow but keeps the app_challenge as part of the state
5. After successful login and /token exchange, the initially provided app_challenge is also persisted as an attribute of the logged-in account
6. The end-user performs an arbitrary set of additional actions within his browser session, e. g. purchases some service, extends his profile, ... Finally, he somehow returns to the surrounding app - either via task switcher, via "back arrow" of the Chrome Custom Tab, or via any other possible way
7. Now, once the app is pulled to foreground again, it remembers that x minutes ago a web session has been triggered, attributed with the app_challenge; the app now tries to exchange the yet local app_verifier at the /token endpoint with its own set of tokens, with the server verifying that there had been a login request with S256(app_verifier) not more than x minutes ago.

For me step 7. would be a perfect candidate of new grant type urn:ietf:params:oauth:grant-type:token-exchange, hence it would be great to know whether there will be (or maybe already is) support for the RFC in AppAuth.

[iainmcgin]

There is no support yet for this RFC, we (the AppAuth maintainers) will have to decide if and how to add support consistently across the three platform implementations (Android, iOS, and JS). @WilliamDenniss @tikurahul any thoughts here?

[rgarofalo]

Hi, is there a solution for this "problem"? I would like to use this mode but before starting to change things, I would like to hear your opinion