A few comments on parts of the OAuth 2.0 Threat Model and Security Considerations:
* [2.1. Scope] "Resource server URLs are static and well-known at development time" is a very strong assumption. It eliminates much of the value of having an OAuth standard (reducing it to aiding some shared code between service-provider libraries). Does a "static and well-known" resource that redirects elsewhere, or includes links to other resources still meet this assumption? * [3.1. Tokens] An "authorization code" doesn't have to be a "handle token". It could be an "assertion". * [3.1. Tokens] A token is called "opaque" when the client app (not the resource server) doesn't need to know anything about its internal structure. * [3.1. Tokens] "MAC" stands for "Message Authentication Code", not "Mutual Authentication". In fact, there is no mutual authentication in the MAC HTTP authentication scheme. * [3.5. Redirect-URI] A client's redirect URI does not have to be pre-registered - that is just a policy choice by some services. I don't think pre-registration helps much when using a web server flow as the redirect-URI is repeated in the client-authenticated request for an access token. * [3.6. Access Token] Using POST cannot "ensure no logging". A best, it minimizes the risk of sensitive values appearing in the authz server's logs. A cache-control header can avoid caching regardless of the HTTP method. * [3.6. Access Token] A short lifetime for a token doesn't "enable the possibility of revocation". It almost does the opposite. It can reduce the need to have any revocation mechanism - you can just wait for the token's to expire instead. * [3.8. Client Authentication] The "client id" is not used to collate a user-authz request and a client request for an access token - the authorization code links those. Similarly, it is the "refresh token", not the "client id", that links an initial token request to subsequent renewals. * [3.8 Client Authentication] The "client id" cannot be used to differentiate user access and client-on-behalf-of-a-user access since it is not sent in either case. Only the access token is sent in the latter case. There are quite a few "tokens" in OAuth2 (access token, refresh token, code, state...) that have two purposes: to bind flows together; and to transfer state via another party. More prominent advice about the required security properties of these tokens would help. When a service chooses to use a handle as a token 5.1.5.11 does say it needs high entropy, but then gives maximum allowed probabilities of two authorization codes colliding (<= 2^-128 or <= 2^-160). It might be more helpful to say "22 randomly-chosen characters from the base64url alphabet (or the base64url-encoding of 16 randomly-chosen bytes) would be a suitable choice for a handle". I don't think there is any advice for tokens that are assertions, not handles. These need a MAC, but also various other fields such as: a key id (so you can smoothly change keys); date; audience; etc. It is definitely would stating that encryption without a MAC is NOT sufficient. Perhaps the best advice is to suggest services adopt a standard assertion format (such as SAML or JWT) if they want to use assertions. Typos: * [2.3.2. Resource Server] Change "on the authorization server" to "on the resource server" in the 1st sentence. * [2.3.3. Client] Change "on the authorization server" to "on the client" in the 1st sentence. -- James Manger
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
