4 ms·

> I thought it was best practice to ask the user to click authorize every time even if they're authorizing the same scope they previously authorized? I've neve

> I thought it was best practice to ask the user to click authorize every time even if they're authorizing the same scope they previously authorized? I've never seen an authorization server that works that way. Because I walked to make sure I wasn't missing anything, I went back and reviewed all the guidance I could find on the matter and can't find any reference to the suggestion you make.

hirsin 7y ago
Facebook does this when you sign into an app you've previously authorized, in native application flows. Microsoft just added this recently as well. We do recommend it to other IDPs. This is only enforced for public clients though that don't have verifiable reply URIs - so web sites are OK.
- couchand 7y ago
  I've only ever implemented web-based OAuth flows, so I haven't seen that behavior. Do they also disallow the use of refresh tokens? It would seem that allowing refresh would let a malicious app get around the requirement.
  - hirsin 7y ago
    If you force a check at the start, refresh token seems fine. That's much preferable than popping ux every hour or whenever the access token expires.
    - couchand 7y ago
      Then what's the point? The malicious app would just keep refreshing so you never see the confirmation again, anyway.
diafygi 7y ago
Hmmm, is there guidance saying that you should auto-redirect? The spec says, "If the authorization server observes multiple attempts to exchange an authorization code for an access token, the authorization server SHOULD attempt to revoke all access tokens already granted based on the compromised authorization code."[1] If an authorization server implements the recommended behavior and an auto-redirect, doesn't that mean that GET requests will no longer be safely considered immutable since they may cause revocation of previous access_tokens? [1]: https://tools.ietf.org/html/rfc6749#section-10.5 https://tools.ietf.org/html/rfc6749#section-10.5
- couchand 7y ago
  I did not get the impression that there is an attempt to reuse the authorization code, but rather that a completely new flow was initiated. Reusing the same authorization code should of course be considered suspicious.
  - diafygi 7y ago
    Ah, yes, that's correct. I guess I was assuming that once you issue a new authorization code, the authorization server should invalidate any previously issued access_tokens/refresh_tokens because the new authorization code represents a new grant. Or are you supposed to wait until the code is sent to the token endpoint (to get the access_token/refresh_token) before invalidating old access_tokens?
    - couchand 7y ago
      For web app clients, you definitely don't want to invalidate other access tokens in case the user has other sessions open. For native clients, the calculus might be different.

hirsin 7y ago

Facebook does this when you sign into an app you've previously authorized, in native application flows. Microsoft just added this recently as well. We do recommend it to other IDPs. This is only enforced for public clients though that don't have verifiable reply URIs - so web sites are OK.

couchand 7y ago
I've only ever implemented web-based OAuth flows, so I haven't seen that behavior. Do they also disallow the use of refresh tokens? It would seem that allowing refresh would let a malicious app get around the requirement.
- hirsin 7y ago
  If you force a check at the start, refresh token seems fine. That's much preferable than popping ux every hour or whenever the access token expires.
  - couchand 7y ago
    Then what's the point? The malicious app would just keep refreshing so you never see the confirmation again, anyway.

diafygi 7y ago

Hmmm, is there guidance saying that you should auto-redirect? The spec says, "If the authorization server observes multiple attempts to exchange an authorization code for an access token, the authorization server SHOULD attempt to revoke all access tokens already granted based on the compromised authorization code."[1] If an authorization server implements the recommended behavior and an auto-redirect, doesn't that mean that GET requests will no longer be safely considered immutable since they may cause revocation of previous access_tokens? [1]: https://tools.ietf.org/html/rfc6749#section-10.5 https://tools.ietf.org/html/rfc6749#section-10.5

couchand 7y ago
I did not get the impression that there is an attempt to reuse the authorization code, but rather that a completely new flow was initiated. Reusing the same authorization code should of course be considered suspicious.
- diafygi 7y ago
  Ah, yes, that's correct. I guess I was assuming that once you issue a new authorization code, the authorization server should invalidate any previously issued access_tokens/refresh_tokens because the new authorization code represents a new grant. Or are you supposed to wait until the code is sent to the token endpoint (to get the access_token/refresh_token) before invalidating old access_tokens?
  - couchand 7y ago
    For web app clients, you definitely don't want to invalidate other access tokens in case the user has other sessions open. For native clients, the calculus might be different.