For the 3.2.3 Token Response, I believe it is quite clear why that should be rejected via this great response from Aaron: https://github.com/oauth-wg/oauth-v2-1/issues/187#issuecomment-2350781735
For 3.2.4 access_denied, I believe the current solution is a 401 or 403 status code, isn't it? Adding error codes to that response is a bit unnecessary, I would say. For 3.2.4 additional error codes don't seem appropriate as the client can't do anything different; this just requires forcing them to explicitly handle each of these. Less error codes are better unless there is a specific different flow we expect the client to go through. Do you believe there is a user relevant flow that would be different based on the different error codes? I like the 3.2.4 display_uri concept, but it is rife with two problems in practice: - The solution is usually for an owner of the client to do something related to the AS, not the user who receives the error, so it doesn't do any good returning it, AND it is often exposing something about the flow to the user that shouldn't be exposed. - The actual instructions that might need to be conveyed are more complex than just a single parameter. Right now this information would be included in the error_description is valuable, I don't see automation being able to do anything clever if this was exposed differently, do you? For the 4.1.2 The authorization response is just a *code* and not complete, focing authorization servers to unnecessarily look up this information doesn't make sense. It could be MAY at best for me. Did you mean to add this to the 3.2.3 Token Response, and it is already exactly defined like this: RECOMMENDED, if identical to the scope requested by the client; otherwise, > REQUIRED. The scope of the access token as described by Section 1.4.1. If you did intend for it to be added to the 4.1.2 I'm going to have to hard disagree, this is exposing information at a time before it is absolutely necessary. The Token doesn't exist before here, so there is nothing the client could do anyway. Is there a reason you would see absolutely needing to know this information before the auth_code flow is complete? Surely even if the user rejected some scopes, you still want to complete the flow and capture the access_token and refresh_token that the AS is going to generate, right? That feels like a better moment to direct the user through some other flow. However even if we embrace the idea of returning the scopes on the redirect back in the authorization response, I can't see what a client would do. The only thing they could attempt to do is plead with the user to accept those scopes. That's a pretty malicious thing to do, the user already rejected those scopes, forcing them through the exact same flow again is not something that makes sense, at least to me, but it isn't the case that this should be SHOULD let alone MUST. I hope each of my concerns are clear, but I'm happy to try to explain any of them in more detail. - Warren On Wed, Jan 29, 2025 at 11:13 PM Nick Watson <nwatson= 40google....@dmarc.ietf.org> wrote: > Hi all, > > I am new to IETF so apologies if I'm not doing this correctly. I had a few > suggestions for things to add to the 2.1 spec based on scenarios > encountered from running a large authorization server. Let me know your > thoughts or if I should be using a different channel (like github) to > contribute issues/suggestions. > > -- > > In “3.2.3. Token Response”, I think it’s worth defining a refresh token > expiration parameter. This could be useful both for refresh token rotation > (as discussed in section 4.3.1.) as well as supporting user selection of > shorter-lived access. A quick search suggests that there’s some existing > usage of refresh_token_expires_in as a parameter name (Microsoft, GitHub). > > In “3.2.4. Error Response”, it would be worth adding access_denied as a > valid error code here for cases where the authorization server denies the > request. (For example, an enterprise user granted access in the past, but > their admin has since disabled the client or scope for their org.) > > In “3.2.4. Error Response” and “4.1.2.1. Error Response”, is it worth > adding another error code like access_denied_by_authorization_server (bad > name, I know) for cases where the authorization server feels it’s useful > and appropriate to distinguish between resource owner denial and > authorization server denial? This may not be needed as authorization > servers are already free to define their own error code extensions, but a > single umbrella error code could be useful for simpler implementations. > > In “3.2.4. Error Response” (and maybe also 5.3.1), it would be useful to > have some sort of “display_uri” parameter that the authorization server can > provide for RPs to open in a browser if they are able. This display_uri > could be used to show a richer error to the resource owner or even be used > for recovery (e.g. reauth). We could also try to spec out what a full-blown > token endpoint-initiated recovery flow might look like. > > In “4.1.2. Authorization Response”, I think we should say that the > authorization server MUST return a scope parameter if the RP included scope > in the request and the granted scopes differ from the requested scopes. > This allows RPs to be informed if the resource owner only grants partial > consent. > > - Nick Watson > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
