As I said in the other note, after reading through the security
considerations section a couple of times, I think it could benefit
from a different organization. Specifically
- keep the introduction, it’s awesome.
- write new sections for each of the following
1) Authorization Tokens
2) Web Application Clients
3) User-Agent Clients
4) Installed Application Clients
5) Authorization Servers
6) Resource Servers
- merge the current text into the appropriate sections.
I took a swing at the authorization tokens text. I tried to capture
most of the relevant items from the current draft, but might have
missed some.
Cheers,
Brian
10.1 Security Considerations for Authorization Tokens
The OAuth2 protocol deals with several types of authorization tokens. This
section describes the assumptions made by the specification about the design of
those tokens.
10.1.1 Authorization Codes
Authorization codes are issued by the authorization server after an end-user
authorization request has been granted. The codes are used shortly after they
are created, and if the client has authentication credentials, the codes are
bound to those credentials. Authorization codes are exchanged for access
tokens and optional refresh tokens.
Authorization codes MUST be unguessable. They should contain at least 64 bits
of entropy generated with a cryptographically strong random number generator.
If an attacker can guess a valid authorization code, they can use that
authorization code with a legitimate client in order to impersonate the victim
resource owner to the client.
Authorization codes are transmitted via http redirects. Authorization servers
MUST use TLS, which protects the authorization code in transit from the
authorization server to the user-agent.
The destination of the HTTP redirect MAY be a network resource such as an http
URI, or MAY be transmitted to the client through other means outside the scope
of this specification. If the redirect refers to an HTTP resource, that
resource SHOULD implement TLS to protect the authorization code in transit from
the user-agent to the client. Regardless of the delivery mechanism, clients
MUST take precautions to protect the confidentiality of the authorization code.
An eavesdropper who who can steal the authorization code can relay it to the
legitimate client to impersonate the victim resource owner.
Values transmitted via HTTP redirects are prone to leakage via several
mechanisms, such as HTTP logs, referer headers, HTTP redirectors, and
user-agent history. This specification requires several mitigations to
mitigate the risk of stolen authorization codes.
Authorization codes MUST be short-lived, and SHOULD be single use. If the
authorization server observes multiple attempts to exchange an authorization
code for an access token, the authorization server SHOULD revoke all access
tokens already granted based on the compromised authorization code.
If the client can be authenticated, the authorization server MUST authenticate
the client and ensure that the authorization code was issued to the same client.
Clients SHOULD redirect the user-agent immediately after receiving an
authorization code, to reduce the risk of the code leaking in the user-agent
history or via a referer header.
10.1.2 Refresh Tokens
Refresh tokens are tokens used to generate new access tokens for an
authorization granted by a resource owner to a client. Refresh tokens are the
most powerful authentication token discussed in this specification. They can
be thought of as alternative passwords for a resource owner’s account. They
are more secure than passwords, because they cannot be guessed, they can be
limited in scope, and they can be bound to client authentication credentials.
The authorization server MUST maintain the link between a refresh token and the
client to whom it was issued.
The authorization server MUST verify the link between the refresh token and
client identity whenever the client’s identity can be authenticated.
When client authentication is required to use a refresh token (i.e. for web
applications clients), recovery from compromised refresh tokens is possible by
rotating the client authentication credentials. This can be faster and less
disruptive than revoking the refresh tokens and requiring that users reapprove
new tokens. An attacker who has stolen the refresh token will not be able to
use the token, since they will not have access to the client authentication
credentials. In order to preserve the property that rotating client
authentication credentials makes stolen refresh tokens useless, authorization
servers MUST NOT transmit refresh tokens without first receiving valid client
authentication.
Refresh tokens MUST be backed by server-side storage in order to allow
end-users to review and revoke access.
Permission to read and write the storage system MUST be restricted to the
authorization server.
Authorization servers MUST NOT store refresh tokens in a recoverable form.
Authorization servers SHOULD store a cryptographically strong one-way hash of
the refresh token instead of storing the token directly. This allows the
authorization server to verify the token when presented by the client, but
reduces the risk of mass compromise of refresh tokens if the authorization
server is compromised.
Authorization servers MUST limit the number of tokens that are issued by a
single user to prevent resource exhaustion attacks. Authorization servers MAY
use LRU or FIFO algorithms to remove tokens in order to make space for new
tokens.
Authorization servers SHOULD limit the number of tokens that are issued by a
single user to a particular client, in order to prevent a single client from
using all of the token storage quota for the user. Authorization servers MAY
use LRU or FIFO algorithms to remove tokens belonging to a particular client in
order to make space for new tokens for that client.
Refresh tokens MUST be unguessable, and SHOULD contain at least 128 bits of
entropy generated with a cryptographically strong random number generator.
Refresh tokens MUST be kept confidential in transit and storage, and shared
only with the authorization server and the client to whom the refresh tokens
were issue.
10.1.3. Access Tokens
Access tokens are shorter-lived versions of refresh tokens.
10.1.3.1 Confidentiality
Access token credentials MUST be kept confidential in transit and storage, and
shared only among the authorization server, the resource servers the
credentials are valid for, and the client to whom the credentials were issued.
10.1.3.2 Leaks
When using the implicit grant type, the access token credentials are
transmitted in the URI fragment, which can expose the credentials to
unauthorized parties via user-agent history or HTTP redirectors.
Clients SHOULD mitigate the risk of leakage of tokens via the user-agent
history either by using iframes, or else by rewriting the document location to
remove the token as soon as it is received.
Authorization servers MUST mitigate the risk of leakage of tokens via HTTP
redirectors by strict matching of pre-registered URIs when transmitting tokens.
10.1.3.3. Scope
The client SHOULD request access token credentials with the minimal scope and
duration necessary. The authorization server SHOULD take the client identity
into account when choosing to honor the request scope, and MAY issue
credentials with a lesser scope than requested.
10.1.3.4 Implementation
There are multiple possible implementations for access tokens. Access tokens
may act as indices into storage at the resource server. They may be signed
using a public/private key pair, with the private key held by the authorization
server and the public key held by the resource servers. Or access tokens may
be generated using a symmetric authentication key such as an HMAC key.
Different implementations offer different trade-offs in terms of security,
availability, performance, and maintenance cost.
10.1.3.4.1 Shared Storage Implementation of Access Tokens
If access tokens are implemented using storage shared by the authorization
server and the resource servers, the storage needs to be adequately protected.
Shared storage implementations of access tokens may be attractive because they
allow easy revocation of tokens. Shared storage solutions may also be
attractive if storage space and network bandwidth is fast and reliable.
Permission to write to the shared storage SHOULD be restricted to the
authorization server.
Resource servers must be able to query the storage system to see whether an
access token is valid, but SHOULD NOT have permission to list valid tokens that
exist in the system. This reduces the risk of compromise of a resource server
leading to mass compromise of access tokens.
Authorization servers MUST NOT store access tokens in a recoverable form.
Authorization servers SHOULD store a cryptographically strong one-way hash of
the access token instead of storing the token directly. This allows the
resource servers to verify the token when presented by the client, but reduces
the risk of mass compromise of access tokens if the storage system is
compromised.
Authorization servers SHOULD protect against resource exhaustion attacks by
limiting the maximum number of access tokens that may be issued by a single
user.
10.1.3.4.2. Public Key Implementations of Access Tokens
Access tokens may be implemented using public key signatures. Public key
signatures may be attractive if storage space or network bandwidth are limited.
Public key based implementations of access tokens make revocation of issued
tokens more complicated. Difficulty of revocation means that access tokens
should have short lifetimes. Access tokens created using public key signatures
must encode all necessary data within the token, and so may be significantly
larger than implementations based on shared storage.
Access to the private key used to sign access tokens MUST be restricted to the
authorization server.
The private key SHOULD be rotated frequently.
Distribution of the public key to resource servers is out of scope of this
specification, but MUST be done securely.
Design of the contents of access tokens is out of scope of this specification,
but MUST allow resource servers to verify the duration and intended purpose of
the token.
Data within the access token MAY need to be kept secret from clients or
resource owners. Tokens MAY be encrypted either using a secret shared between
resource servers and the authorization server, or using public key encryption
with a private key held by the resource server.
10.1.3.4.3. Shared Secret Implementations of Access Tokens
Access tokens may be implemented using HMAC authentication of the token
contents with secrets shared between authorization servers and resource
servers. Considerations for HMAC authentication of tokens are very similar to
those for public key authentication of tokens, with some important differences.
The primary reason to prefer HMAC authentication of tokens over public key
authentication is that HMAC verification requires less CPU than public key
verification.
HMAC authentication requires that the resource server know the authentication
secret used by the authorization server to create access tokens. Compromise of
the resource server allows an attacker to create new access tokens for all
resource servers that trust the same symmetric key. Because of this,
authorization servers MUST use different authentication keys for each resource
server.
Distribution of the authentication keys is out of scope of this specification.
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
