The Secret Security Wiki

Categories

Home > Wikis > Protocol > Open Authorization

Categories

Open Authorization

OAuth is an open standard that allows users to provide websites or applications with delegated access to their information that is stored on other websites or applications without giving the credentials (i.e. password) that directly access the account where the information is stored. Instead, a delegated access token is provided which specifies access permissions. For example, companies like Amazon, Google, Facebook, Microsoft and Twitter enable users to share information in their accounts with third party applications or websites using mechanisms provided by OAuth.

OAuth 2 protocol includes the following entities:

  • Client Application: a web or mobile application that requires access to user data on another website or application.
  • Resource Owner (RO): a user that owns data and authorizes a Client Application to access the data.
  • Resource Server (RS): a website or application that stores the data owned by the Resource Owner.
  • Authorization Server (AS): a security token service that is linked to the Resource Server, which issues access tokens to data stored on the Resource Server.

Designed specifically to work with Hypertext Transfer Protocol (HTTP), OAuth essentially allows access tokens to be issued to third-party Client Applications by an Authorization Server with the approval of the Resource Owner. The third party then uses the access token to access the data which is hosted by the Resource Server.

The OAuth authorization process begins with an end user (Resource Owner) specifying that she wants to provide a Client Application with access to data on a third-party application (Resource Server). The Client Application redirects this request to an Authorization Server linked to the Resource Server, which authenticates the requesting end user (Resource Owner). The Authorization Server then authorizes the Client Application to access the user’s data on the Resource Server and redirects the user back to the Client Application with a single-use access code.

The single-use access code is sent back to the Authorization Server, where it is converted into an access token that the Client Application may use to access the Resource Server. At the same time, the Authorization Server may also send back a refresh token which will allow the Client Application to request a new access token when the current one expires.

OAuth is a service that is complementary to and distinct from OpenID Connect (ODIC). ODIC and OAuth are often used together, with OIDC providing the user authentication layer and OAuth as the authorization/delegated access layer.

OAuth is an authorization protocol, and not an authentication protocol, though it is sometimes used on its own as an authentication method – sometimes referred to as pseudo-authentication.  The user (Resource Owner) is typically authenticated in the process of granting the OAuth access token, meaning that OAuth is sometimes viewed as an authentication method. However, OAuth was not designed with this use case in mind and making this assumption can lead to major security flaws.

The OAuth 1.0 protocol was published as RFC 5849 in April 2010. The OAuth 2.0 framework was published as RFCs 6749 and 6750 in October 2012.

OAuth 2.0 is not backwards compatible with OAuth 1.0. OAuth 2.0 provides specific authorization flows for web applications, desktop applications, mobile phones, and smart devices.

Because OAuth 2.0 is more of a framework than a defined protocol, one OAuth 2.0 implementation is not necessarily inter-operable with another OAuth 2.0 implementation.

  • What is OAuth 2.0?

    OAuth 2.0 is a delegated access framework that was published as RFC 6749 and 6750 in October 2012. OAuth 2.0 is not backwards compatible with OAuth 1.0 and provides specific authorization flows for web applications, desktop applications, mobile phones, and smart devices.

  • What is the use of 0Auth?

    OAuth is an open standard that allows users to provide websites or applications with delegated access to information that is stored on other websites or applications, without giving the application or website credentials to directly access the account (i.e. password) where the information is stored.

  • What is the difference between OAuth and SAML?

    Security Assertion Markup Language (SAML) is an XML-based standard data format for exchanging authentication and authorization data between an identity provider and a service provider. OAuth is an open standard that allows users to provide websites or applications with delegated access to information that is stored on other websites or applications, without giving the application or website credentials to directly access the account (i.e. password) where the information is stored.

    OAuth can use different token formats, including JSON Web Token (JWT) and the SAML token format.

  • Is JWT an OAuth?

    JSON Web Token (JWT) defines a token format and OAuth is a protocol that specifies how tokens are obtained and transferred. OAuth may use a JWT as a token format but can use other formats as well.

  • Is OpenID the same as OAuth?

    OAuth is a service that is complementary to and distinct from OpenID Connect (ODIC). ODIC and OAuth are often used together with OIDC providing the user authentication layer and OAuth as the authorization/delegated access layer.

  • How does OAuth work?

    The OAuth authorization process begins with an end user (Resource Owner) specifying that she wants to provide a client application (Client) with access to data on a third-party application (Resource Server). The client application redirects this request to an Authorization Server provided by the third-party application (Resource Server), which authenticates the requesting end user (Resource Owner). The Authorization Server then authorizes the client application and the Resource Owner and redirects the user back to the client application with a single-use access code.

    The single-use access code is sent back to the Authorization Server, which then converts it into an access token that the end user may use to access the server. At the same time, the AS may also send back a refresh token, which will allow the end user to use the same OAuth to access more than once.

    Essentially, the access token allows a user to call the API. In return, the API gains access to information about both the client and the resource owner and what path they took, what client they are using, and who is the end user.

  • What are Grant types?

    The OAuth 2.0 authorization framework describes several methods a Client Application can use to acquire an access token that can be used to authenticate a request to an API endpoint of a Resource Server. The different methods are called grant types. The specification describes five grants for acquiring an access token:

    • Authorization code: An authorization code grant is sent to the Client Application via browser redirect, and the authorization code is used in the background to get an access token.
    • Implicit: The implicit grant is similar to the authorization code, but instead of using the code as an intermediary, the access token is sent directly through a browser redirect.
    • Resource Owner credentials: The password/Resource Owner Credentials grant uses the Resource Owner password to obtain the access token. The password is then discarded.
    • Client Application credentials: In client credentials grant mode, the Client Application’s credentials are used instead of the Resource Owner’s.
    • Refresh Token: The refresh token is used to get a new access token when the old one expires.

  • Which type of tokens does OAuth uses?

    The two token types involved in OAuth 2 authentication are Access Token and Refresh Token.

    The Access Token is used for authorizing a request to get access to data from the Resource Server.

    The Refresh Token is normally sent together with the Access Token and used to get a new Access Token when the old one expires. The Refresh Token is used as a grant type to receive a new Access Token. Using Refresh Tokens allows issuing Access Tokens with short expiration time while maintaining a longer expiration time for accessing the Authorization Server.

  • Is OAuth an identity as a service (IDaaS) Solution?

    Identity as a Service (IDaaS) is cloud-based identity and access management (IAM) service operated by a third-party provider. Using IDaaS, subscribing companies can validate user credentials and provide access to resources and/or relyingthe parties that have a trust relationship with the IDaaS. IDaaS is particularly relevant for enterprises that are ‘all-in’ on cloud services and do not manage their own network or host their own servers and applications.

    OAuth is an open standard that allows users to provide websites or applications with delegated access to their information that is stored on other websites or applications, without giving the application or website credentials to directly access the account (i.e. password) where the information is stored.

    Because the user (Resource Owner) is typically authenticated in the process of granting the OAuth access token, the OAuth token is sometimes viewed as an authentication method, and because it is a third party that does the authenticating, OAuth is sometimes confused with IDaaS. That said, OAuth is not an IDaaS and should not be used for authenticating users.