kapehe-jorgenson

Kapehe is an R&D Content Engineer for Auth0 with a passion for learning and teaching. With her primary focus on ReactJS and JavaScript, she is impressed with what code can create for the web. Technology and web development are constantly evolving and naturally bring that need for continual learning. She enjoys writing tutorials, hosting local meetups, and learning with others to expand coding knowledge.

R&D Content Engineer

Kapehe Jorgenson

A brief overview of the top identity open standards used today.



**TL;DR:** In this overview, we will go over what open standards are and why they matter. We will also go over the top open standards used for identity including OAuth 2, OpenID Connect, JWT, and SAML. Open standards are important to understand but one can easily get overwhelmed by the technical specifications.

<include src="TweetQuote" quoteText="An overview of the top open standards used for identity including OAuth 2, OpenID Connect, JWT, and SAML."/>

## What is an Open Standard?
Identity, and the infrastructure that goes behind making identity **secure**, **lightweight**, and **reliable**, can be a challenge, one that can take up a lot of your team’s time to get just right. One way to reduce the overhead is to utilize open standards, rather than reinventing the wheel.

Open standards are community and industry-driven specifications that can define roles for an app, whether that role is the user, the identity provider, or the service provider, and how those roles talk to each other. Standards also define how apps are able to communicate with each other and to service providers. This can all happen without compromising key details or code.

Open standards can be implemented across many languages, platforms, and technologies, making it easy for a wide variety of organizations to utilize their benefits. 

The formation of open standards has created a uniform way of expressing the fundamental keys of identity across the industry, while still allowing flexibility around the specific path of implementation.

<include src="TweetQuote" quoteText="Open standards can be implemented across many languages, platforms, and technologies, making it easy for a wide variety of organizations to utilize their benefits."/>

### Open Standards You May Know

Modern web development relies on a range of well-known open standards that you may already be familiar with. They cover many facets of web development, from **JSON** (JavaScript Object Notation), used to structure data in a readable format, to **HTML** (HyperText Markup Language), used for creating web pages, all the way to **SAML** (Security Assertion Markup Language),  which is used for enterprise identities as described below.

## Four Common Open Standards for Authentication and Authorization

### OAuth 2
OAuth 2 is the latest version of the OAuth protocol, allowing for **better authorization flow across many devices and applications**. Users can grant a third-party website limited access to their information on another website without exposing their credentials. 

OAuth 2 is one of the most widely used open standards for delegating access, one that you as a user probably see implemented often. For example, when you log in to a website that wants access to information from your Google account (i.e., contacts), you grant authorization via OAuth 2. You can find the official docs for [OAuth 2 here](https://tools.ietf.org/html/rfc6749) and view [Auth0's thorough overview of OAuth 2](https://auth0.com/blog/oauth2-the-complete-guide/).

### OIDC (OpenID Connect)
OpenID Connect is an extra identity layer built on top of OAuth 2 that specifies a process for checking a user’s identity by ensuring they are who they say they are.

> OIDC is able to retrieve the user’s basic profile information from the identity provider. 

For example, when a user visits a website and can log-in via Google or Facebook, that application will then go to Google or Facebook and get those user's credentials. The application then does not have to store the user's basic profile and can utilize Google or Facebook and their storage of the user's information to grant access and verify their identity.

OpenID Connect is _API-friendly_ and can be used across mobile applications, web-based applications, all JavaScript clients, and many other types of clients. OIDC also requires the use of JSON Web Tokens which we will get into next. You can find the official docs for [OpenID Connect here](https://openid.net/connect/).

### JWT (JSON Web Tokens) 
Sending information, such as user data, across many different applications can be done using **JSON Web Tokens**. JSON web tokens hash information into a long, encoded string of characters that can be broken into three parts:

* The header that declares the hashing algorithm and the token type. 
* The payload or data where you could have the name of the user or other relevant information like the token expiration time or the subject. 
* The verifying signature made up of the header, payload, and a secret all hashed together. 

The JWT can get long, but this open standard provides a straightforward way to transfer information. If you visit [jwt.io](https://jwt.io/), there is a tool there where you can put in any encoded JWT and it will decode it for you as follows:

**JWT - encoded:**

```
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
```

**JWT - decoded:**

Header:

```json
{
  "alg": "HS256",
  "typ": "JWT"
}
```

Payload:

```json
{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}
```

Verify Signature:

```
HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  your-256-bit-secret
) secret base64 encoded
```

JWTs can be verified and trusted because they have a **digital signature**. That digital signature verifies that nothing was changed while the JWT was being passed. You can find more information on [JWTs here](https://auth0.com/learn/json-web-tokens/).

### SAML (Security Assertion Markup Language)
An XML-based open standard, SAML ensures that there is a secure communication of identities between organizations. This is a great tool for businesses when they want to communicate user authentication and authorization information to other organizations that their employee may need access to. Some benefits include:

* Increased security through a single point of authentication
* Improved user experience by utilizing a single sign-on access point.
* A centralized user access control allowing for a one-stop authentication point

SAML utilizes a _SSO (single sign-on) format_. Digitally signed XML documents are passed between the business and multiple third-party entities they have partnered up with. You can find [more information on SAML here](https://auth0.com/blog/how-saml-authentication-works/).

---

## Summary

As we have learned, the flexibility of open standards allows for the identity industry to be on the same page, reduce overhead, and create a uniform way of expressing the **fundamental keys of identity**. When everyone implements a standard way of doing things, then the _flow_ over different languages, projects, and teams can go as planned with authentication and authorization.

At Auth0 we use open standards so that we can connect our product to users and clients alike in a **standard and secure** way. Identity can be tricky, but here at Auth0 you can rest assured that your users are backed by industry-defined open standards. We use open standards to provide you with a secure solution that can be implemented in a matter of minutes. We have you covered, open standards and all.

Want to continue learning about these open standards? Visit the Auth0 docs for the above mentioned open standards: 

* [OAuth 2](https://auth0.com/docs/protocols/oauth2)
* [OpenID Connect](https://auth0.com/docs/protocols/oidc)
* [JWTs](https://auth0.com/docs/jwt)
* [SAML](https://auth0.com/docs/protocols/saml/saml-configuration)

<a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">Sign up for a free Auth0 account here</a>


An Overview of Open Standards

eHk3ciM

I am the Group Manager, Developer Content at Okta, and a Google Developer Expert in Web Technologies and Angular. I'm passionate about identity, authentication, constant learning, and developer communities. As a developer advocate, engineer, mentor, and international speaker, I love learning from and sharing with other inhabitants of the tech space.

Group Manager, Developer Content

Kim Maida

The IETF has released Best Current Practice (BCP) for OAuth 2.0 in native apps. Learn about it now.



**TL;DR:** In October, 2017, the [Internet Engineering Task Force (IETF)](https://www.ietf.org/) released the [Best Current Practices (BCP) when using OAuth 2.0 with native mobile applications](https://www.rfc-editor.org/rfc/rfc8252.txt). This BCP states that OAuth 2.0 authorization requests from native apps should _only_ be made through external user agents, primarily the user's browser. We'll discuss what this means for developers and users and any security considerations involved.

---

## OAuth 2.0 Best Current Practice for Native Apps

The IETF ([Internet Engineering Task Force](https://www.ietf.org/)) recently released the [Best Current Practice for OAuth 2.0 for Native Apps Request For Comments](https://www.rfc-editor.org/rfc/rfc8252.txt). This document requires that, in accordance with best practices, only external user agents (such as the browser) should be used with the [OAuth 2.0 Authorization Framework](https://tools.ietf.org/html/rfc6749) by native applications; this is known as the "AppAuth pattern". Embedded user agents should not be implemented.

> _For authorizing users in native apps, the best current practice is to perform the OAuth authorization request in an external user agent (typically the browser) rather than an embedded user agent (such as one implemented with web-views)._
>
> -_[OAuth 2.0 for Native Apps](https://www.rfc-editor.org/rfc/rfc8252.txt)_

Using the browser to make native app authorization requests results in better security. It also enables use of the user's current authentication state, making single sign-on possible. Embedded user agents are unsafe for third parties. If used, the app has access to the OAuth authorization grant as well as the user's credentials, leaving this data vulnerable to recording or malicious use. Embedded user agents also don't share authentication state, meaning no single sign-on benefits can be conferred.

We'll go into the security and implementation advantages of using the browser for authorization requests in more detail below.

<include src="TweetQuote" quoteText="Using the browser to make native app authorization requests results in better security."/>

### Authorization Flow for Native Apps Using the Browser

The authorization flow for native apps using the browser acts as illustrated in the following diagram:

![Authorization flow for OAuth 2.0 in native apps using the browser](https://images.ctfassets.net/23aumh6u8s0i/3ULKZFPLQiGXHa9NFNCpCS/bd5c463c34ae60a1aee86af0db199b3a/hoauth-flow)

> 1. Client app opens a browser tab with the authorization request.
2. Authorization endpoint receives the authorization request, authenticates the user, and obtains authorization. Authenticating the user may involve chaining to other authentication systems.
3. Authorization server issues an authorization code to the redirect URI.
4. Client receives the authorization code from the redirect URI.
5. Client app presents the authorization code at the token endpoint.
6. Token endpoint validates the authorization code and issues the tokens requested.
>
> _Figure 1, [OAuth 2.0 for Native Apps](https://www.rfc-editor.org/rfc/rfc8252.txt)_

URIs are used for OAuth 2.0 on the web for authorization requests and responses. Similarly, URIs can also be used in native apps. When the built-in browser is employed by the user for all native app logins, certain advantages are conferred, such as the ability to use a single sign-on session stored in a central location and additional security afforded by an authentication context that is separated from the app. Browser security is also a major focus of vendors, and they tend to manage security and sessions policies quite well. In addition, supporting and implementing the same approach in web and native apps reduces complexity and increases interoperability.

<include src="TweetQuote" quoteText="Implementing external user agents in both web & native apps reduces complexity and increases interop."/>

### Initiating and Receiving Authorization Requests

Native apps now must request user authorization by creating a URI with the appropriate [grant type specified in the OAuth 2.0 Authorization Framework](https://tools.ietf.org/html/rfc6749#section-4.1). The app then redirects the user to this request URI. A redirect URI that the native app can receive and parse appropriately must also be supplied. This must be implemented using an _external user agent_. Use of the device browser is recommended.

The authorization server must permit at least three redirect URI options for the response sent back to the native app:

* Private-Use URI Scheme Redirection
* Claimed "https" Scheme URI Redirection
* Loopback Interface Redirection

You can read about these three options in detail in Section 7 of [OAuth 2.0 for Native Apps](https://www.rfc-editor.org/rfc/rfc8252.txt).

## OAuth 2.0 Security Considerations for Native Apps

When implementing OAuth 2.0, there are a number of security considerations that developers must be mindful of when using best current practice with an external user agent. We'll go over a few of them now.

### Authorization Code and Grant Flow

Using the redirect options above means that the authorization code can only be received by native apps on the same device. While this increases security, it does still mean that another app on the same device could potentially intercept the code. The [Proof Key for Code Exchange (PKCE) protocol](https://tools.ietf.org/html/rfc7636) was created to defend against this attack vector. Public apps as well as servers _must_ use PKCE, and servers should reject authorization requests from apps that do not.

It is _not_ recommended to implement [implicit grant flow](https://auth0.com/docs/api-auth/grant/implicit) in native apps because this flow cannot be protected by PKCE. Instead, [authorization code grant flow with PKCE](https://auth0.com/docs/api-auth/grant/authorization-code-pkce) should be used.

### Authorization Servers and Clients

In most cases, native apps are considered public clients and must be registered with the authorization server. Authorization servers must also register a client's complete redirect URI. If an authorization request does not match the registered redirect URI, the request must be rejected.

User authentication and consent will be required by the authorization server, as per any other web browser based OAuth 2.0 flows.

### User Agents

Embedded user agents should not be used to masquerade as an external user agent. Authorization servers can protect against these fake agents by requiring an authentication factor only available to genuine external user agents.

Cross-Site Request Forgery (CSRF) attacks should also be mitigated by using the `state` parameter to link client requests and responses. More details are available in section 5.3.5 of [OAuth 2.0 Threat Model and Security Considerations](https://tools.ietf.org/html/rfc6819).

The user's browser is the recommended external user agent. Embedded user agents must not be used for authorization requests. Authorization servers may detect and block requests from embedded user agents, as they are unsafe for third parties, such as the authorization server itself. The reason for this is because the app can then access not only the OAuth authorization grant, but also the user's full authentication credentials. The app could then potentially record or use this information maliciously. In addition, embedded user agents don't share authentication state with other apps or the browser and therefore disabling single sign-on benefits.

## Conclusion

If you're a native app developer, it's very important to adhere to best current practices. Please take the time to read over the [OAuth 2.0 for Native Apps](https://www.rfc-editor.org/rfc/rfc8252.txt) RFC yourself. Using an external user agent for OAuth 2.0 authorization requests provides better security as well as an improved user experience as it enables [single sign-on](https://auth0.com/blog/what-is-and-how-does-single-sign-on-work/) across the device's apps and browser.

### Centralized Login with Auth0

[Auth0](https://auth0.com) provides a [centralized login approach](https://auth0.com/docs/hosted-pages/login) that adheres to the OAuth 2.0 Best Current Practice for native apps. Centralized login provides the most secure experience and is also easy to implement for developers. A URI is used to trigger an authentication request and the centralized login page is shown to users. This login page can use the [Auth0 Lock widget](https://auth0.com/lock) or your own custom UI. After authorization, the user is returned to your app via your provided redirect. Auth0 provides extensive documentation to help you easily implement the appropriate flows to keep your apps secure and user-friendly as well.

Check out the following resources to learn more about implementing Auth0 with centralized login in your native apps in accordance with the OAuth 2.0 Best Current Practice:

* [Centralized Login Page](https://auth0.com/docs/hosted-pages/login)
* [OAuth 2.0](https://auth0.com/docs/protocols/oauth2)
* [Calling APIs from Mobile Apps (Authorization Code PKCE)](https://auth0.com/docs/api-auth/grant/authorization-code-pkce)
* [iOS Swift Quickstart - Login](https://auth0.com/docs/quickstart/native/ios-swift/00-login)
* [Android Quickstart - Login](https://auth0.com/docs/quickstart/native/android/00-login)

You can sign up for a <a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">free Auth0 account now</a> and get started right away, or check out [Auth0's pricing here](https://auth0.com/pricing).


"oauth-2"