Subject: [OAUTH-WG] Comments on draft-lodderstedt-oauth-security

From: "Manger, James H" <[email-masked]>
Date: Tue, 29 Mar 2011 16:57:09 +1100

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