OAuth 2.0 Profiles


The OAuth 2.0 specification also mentions that the "framework was designed with the clear expectation that future work will define prescriptive profiles and extensions necessary to achieve full web-scale interoperability."

The OAuth 2.0 Profiles are concrete types of applications, that can be either confidential or public. The profiles are:

User Managed Access#

User Managed Access (UMA) is a profile of OAuth 2.0 implemented by the another standard.

Web Application#

A web application is an application running on a web server. In reality, a web application typically consists of both a browser part and a server part. If a web application needs access to a Resource Server (e.g. to Facebook user accounts), then the client password could be stored on the server. The password would thus be confidential.

A web application is a confidential client running on a web server. Resource Owners access the OAuth Client via an HTML user interface rendered in a user-agent on the device used by the Resource Owner. The OAuth Client credentials as well as any Access Token issued to the client are stored on the web server and are not exposed to or accessible by the Resource Owner

user-agent-based application#

A user-agent-based application is a public OAuth Client in which the OAuth Client code is downloaded from a web server and executes within a user-agent (e.g., web browser) on the device used by the Resource Owner. Protocol data and credentials are easily accessible (and often visible) to the Resource Owner. Since such applications reside within the user-agent, they can make seamless use of the user-agent capabilities when requesting authorization.

native application#

A native application is typically a OAuth Public Client installed and executed on the device used by the Resource Owner. Protocol data and credentials are accessible to the Resource Owner. It is assumed that any client authentication credentials included in the application can be extracted. On the other hand, dynamically issued credentials such as Access Tokens or Refresh Tokens can receive an acceptable level of protection. At a minimum, these credentials are protected from hostile servers with which the application may interact. On some platforms, these credentials might be protected from other applications residing on the same device. (Related information is Native Applications Working Group

OpenID Connect Profiles#

More Information#

There might be more information for this subject on one of the following: