Messages - Clarification of statement about interacting with a token endpoint needed
Issue #341
resolved
The spec currently says “Access Token Request / Responses interact with a Token Endpoint. Upon a successful request, it returns an Access Token and an ID Token.”
First, isn’t it true that this is only the case when the implicit flow is not used (when using the token flow)? If so, the spec should say this. Second, given we want to save round trips, what are the circumstances under which implementations would want to pay the extra round trip to use the token endpoint?
Finally, assuming that we define how to receive only the id_token but not an access token, the statement that "it returns an Access Token and an ID Token" will also need to be corrected.
Comments (5)
-
-
reporter
The main point of this issue is that use of the Token endpoint is *not* flow independent. It is specific to a particular OAuth 2.0 flow. As such, this description probably belongs in Standard, not in Messages.
Per the id_token-only response, I don't actually think this is up to the OAuth community. They've defined a genaral extension mechanism. OpenID Connect is using it. Unless the remove the extension mechanism from the spec before approval, OpenID Connect is on solid ground defining the semantics fo the id_token (only) return type.
-
-
assigned issue to
Nat Sakimura
- changed status to open
Add clarifier. Figure out if it affects standard as well.
-
assigned issue to
-
First, Messages just lists the possible responses. Has nothing to do with flows. Bindings define what actually needs to be returned.
Second, "given we want to save round trips" is just one view. It is not universally true. It has to be weight against other factors. Sometimes, you would not want to expose the access token to the browser.
Third, Clarified the sentences in Messages that Token EP can return access token, refresh token, id token and other variables.
-
- changed status to resolved
Fix
#341Messages - Clarification on Token endoint - Log in to comment
Message is just defining the messages between the client and each endpoints. It is flow independent. Actual binding to each protocol will be defined in binding specs, e.g., Standard.
The spec. currently says "access token and id token" because the OAuth core says it MUST return access token for a positive response. It remains to be seen if oauth community accepts id_token only response as OAuth.