The OAuth 2.0 Authorization Framework

en · official · sha256:12d44453a7b68d70f4cee31dc0a880ba54636c52e19dca9c10f68fb4e915fdf0

Hardt Standards Track [Page 9]  RFC 6749 OAuth 2.0 October 2012 1.4. Access Token Access tokens are credentials used to access protected resources. An access token is a string representing an authorization issued to the client. The string is usually opaque to the client. Tokens represent specific scopes and durations of access, granted by the resource owner, and enforced by the resource server and authorization server. The token may denote an identifier used to retrieve the authorization information or may self-contain the authorization information in a verifiable manner (i.e., a token string consisting of some data and a signature). Additional authentication credentials, which are beyond the scope of this specification, may be required in order for the client to use a token. The access token provides an abstraction layer, replacing different authorization constructs (e.g., username and password) with a single token understood by the resource server. This abstraction enables

Referencing norms: DirectlyIssuedTokenIsRootAuthority, TokenIsAuthorityFromOwnerToClient

en · official · sha256:b71e5c08ed8e2de56469ba40dca9d67a6e8c43eeef1d94c13f677923e495214f

to understand a wide range of authentication methods. Access tokens can have different formats, structures, and methods of utilization (e.g., cryptographic properties) based on the resource server security requirements. Access token attributes and the methods used to access protected resources are beyond the scope of this specification and are defined by companion specifications such as [RFC6750]. 1.5. Refresh Token Refresh tokens are credentials used to obtain access tokens. Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires, or to obtain additional access tokens

Referencing norms: AccessTokenFromRefreshIsSubdelegation, RefreshTokenIsNeverSentToResourceServers, RefreshTokenIsRootAuthority, RefreshTokenPermitsObtainingAccessTokens

en · official · sha256:c39f78c8a4f837e4b52093c7e84c4edef702e2e48c4f0e4277b89694fbf093ce

set of client credentials is significantly easier. Hardt Standards Track [Page 22]  RFC 6749 OAuth 2.0 October 2012 A client MAY use the "client_id" request parameter to identify itself when sending requests to the token endpoint. In the "authorization_code" "grant_type" request to the token endpoint, an unauthenticated client MUST send its "client_id" to prevent itself from inadvertently accepting a code intended for a client with a different "client_id". This protects the client from substitution of the authentication code. (It provides no additional security for the protected resource.) 3.3. Access Token Scope The authorization and token endpoints allow the client to specify the scope of the access request using the "scope" request parameter. In turn, the authorization server uses the "scope" response parameter to inform the client of the scope of the access token issued.

Referencing norms: ScopeTokenIsCoveredAct

en · official · sha256:834d8ee546bacf3111e1a04932799bd3efaa68bd85a50d4b4b491de15400ed1e

Hardt Standards Track [Page 42]  RFC 6749 OAuth 2.0 October 2012 For example, to request an access token using a Security Assertion Markup Language (SAML) 2.0 assertion grant type as defined by [OAuth-SAML2], the client could make the following HTTP request using TLS (with extra line breaks for display purposes only): POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded

Referencing norms: ExpiryDayClosesLifetime, IssueDayOpensLifetime