Open rockebee opened 4 years ago
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?
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
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:
app_verifier
and a corresponding S256 hash of it (app_challenge
) => obviously borrowed from PKCEapp_challenge
being part or URL query parametersapp_challenge
as an extra param to the/authorization
endpointapp_challenge
as part of the state/token
exchange, the initially providedapp_challenge
is also persisted as an attribute of the logged-in accountapp_challenge
; the app now tries to exchange the yet localapp_verifier
at the/token
endpoint with its own set of tokens, with the server verifying that there had been a login request withS256(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.