OAuth

Without OAuth, a resource owner who wants a third-party application to reach their data has to share their credentials with it. The application then stores the password, often in clear text, gains overly broad access, and cannot be cut off without changing the password, which cuts off every other application too. OAuth adds an authorization layer that separates the client from the resource owner: the client obtains an access token, a string denoting a specific scope, lifetime, and other access attributes, instead of using the owner's credentials.

OAuth defines four roles. The resource owner can grant access to a protected resource; the resource server hosts it; the client is the application making requests on the owner's behalf; and the authorization server issues access tokens to the client after authenticating the resource owner and obtaining authorization. RFC 6749 defines four grant types: authorization code, implicit, resource owner password credentials, and client credentials.

OAuth 2.0 was published as RFC 6749 in October 2012. It replaces and obsoletes OAuth 1.0 and is not backward compatible with it. CISA and NSA guidance describes OAuth 2.0 as designed only for authorization, granting access to data and features from one application to another; OpenID Connect is a thin layer on top of OAuth 2.0 that adds login and profile information about the person who is logged in.

RFC 9700, the IETF best current practice for OAuth 2.0 security, updates the original threat model and deprecates modes of operation considered less secure or insecure. The resource owner password credentials grant must not be used, because it exposes the owner's credentials to the client. Clients should not use the implicit grant, which is vulnerable to access token leakage and replay, and public clients must use PKCE to protect the authorization code flow.