OAuth 2.0 Identity and Access Management Patterns

3.5 (2 reviews total)
By Martin Spasovski
    Advance your knowledge in tech with a Packt subscription

  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies

About this book

OAuth 2.0 has become the most widely used authorization framework. It provides an easy-to-use sign-in mechanism and allows users to quickly and efficiently secure service APIs. It also provides a protection layer for assets so that various third-party applications cannot have direct access to them. From service providers like Amazon and social media platforms like Facebook and Twitter to various internal enterprise solutions, OAuth 2.0 is the preferred standard for authorization.

OAuth 2.0 Identity and Access Management Patterns is a step-by-step guide to build web, client-side, desktop, and server-side secure OAuth 2.0 client applications by utilizing the appropriate authorization techniques.. This book will help you handle and implement various authorization flows for your chosen type of application. Furthermore, you will understand when and how OAuth 2.0 is used in enterprises for trusted and first-party applications. You will gain knowledge about the Resource Owner Password Credentials grant and the Client Credentials grant, and more importantly, you will understand how to implement them yourself with the help of practical code examples.

You will start by making various client applications step-by-step before moving on to client registration and implementing various OAuth 2.0 authorization flows. Furthermore, you will also be handling server responses with access tokens and errors. By the end of this book, you should understand precisely what it takes for these client applications to be secured.

This book helps you cover each type of application: web, client-side, desktop, and trusted applications. In addition, you are also shown how to implement various authorization grant flows for each of these applications. You will uncover the security features that are a part of OAuth 2.0. More importantly, the book demonstrates what information is transmitted during the execution of a flow, and which precautions can be made. With OAuth 2.0 Identity and Access Management Patterns, you will be able to build a secure OAuth 2.0 client application with full confidence and will completely understand what data is exchanged when performing an authorization grant flow.


Publication date:
November 2013


Chapter 1. Need for OAuth 2.0

OAuth 2.0 can be perceived as a protective layer for a given service, so that the client applications that are built for the service can have a standardized method of requesting the protected resources that belong to a user who uses the system, or resources that belong to the service in general. These resources may vary from various data that the user has stored, to various application programming interface (API) methods for system maintenance and more. The client applications, in order to obtain these protected resources, make HTTP requests to the predefined service endpoints and supply an access token— a token that says which user has approved the client application to access its data. OAuth 2.0 is a protocol that has found its place as an authorization framework in various services that are provided to clients, most commonly securing RESTful APIs and web-based applications. Additionally, when businesses want to communicate to other businesses purely by exchanging resources via services in a B2B manner, OAuth 2.0 can be used.


The OAuth 2.0 specification is fully named "The OAuth 2.0 Authorization Framework". It outlines the OAuth 2.0 protocol and leaves some points to be flexible and implemented in various ways; that's why it is important not to confuse it with a framework as in a technology stack; the term framework here means that the protocol can be implemented in various ways.

There are more cases, but what is evident is that OAuth 2.0 is able to handle the authorization layer in systems, providing access to protected resources in various scenarios, environments, and devices. Additionally, when it provides access, it does that on behalf of someone (most commonly the resource owner)—who is identified by the access token. But more details later.

More and more enterprises started using OAuth 1.0 and migrated to OAuth 2.0, from payment services such as PayPal and service providers such as Amazon to social media platforms, such as Facebook and Twitter, and various internal enterprise solutions. It's used in various scenarios, from securing service APIs to providing an easy-to-use sign-in mechanism and more. What we can notice is that OAuth 2.0 is found in enterprises in two ways: they use it and/or they support it. When enterprises consume protected resources from other service providers that are secured with OAuth 2.0, we say they use it (they may do the same internally between their own systems). Additionally, when enterprises secure their own services with OAuth 2.0 or provide OAuth-based solutions so that other enterprises can secure their services, we say they support it.


Why OAuth 2.0?

As the usage increased, developers ran into some common problems during the implementation phase, for both service providers and client applications. In OAuth 1.0, the use of cryptographic functions are a part of the protocol, which adds to the difficulty of the developers implementing it. Later on a security flaw was discovered, which had to be resolved, and resulted in a revised specification named OAuth 1.0a. Previous specifications also had a bad design decision. The use of Secure Sockets Layer (SSL) in order to secure data transfer between the parties that are part of the authorization flow was not mandatory, which meant sensitive information could be exposed.

Additionally, there were use cases that were not defined and could have been like the various authorization flows that are part of OAuth 2.0. It was evident that improvements could be made to the original OAuth 1.0 specification.

Development took off to define a new revised specification, versioned 2.0, authored by a bigger team and based on their experience in OAuth 1.0 implementations and deployments, on comments from the wider community, and on the additional OAuth 1.0 based specifications that were created meanwhile (and had the common goal of adding additional capabilities that were needed but not available in OAuth 1.0).

This resulted in the OAuth 2.0 authorization framework, delivering key improvements especially by simplifying and defining more clearly the way client developers should implement authorization against providers, in order to access protected resources.


OAuth 2.0 is not backwards compatible with 1.0, as they don't share a lot of similarities in implementation details, and they differ in the structure of exchanged information.

Therefore, developers that have worked with OAuth 1.0 should not make assumptions about OAuth 2.0 without getting familiar with it in the first place. Implementations for both 1.0 and 2.0 can co-exist for a given provider if it is chosen to support both, due to legacy clients, for example.

Support from service providers is leaning towards OAuth 2.0. A rough estimate of the percentage between providers that support OAuth 2.0 compared to OAuth 1.0 shows that at least 60 percent are in favor of OAuth 2.0. Some exclusively support OAuth 2.0 (a notable example of this is Facebook with its Graph API), some support OAuth 2.0 and announced deprecation of OAuth 1.0 (for example, Google), and some service providers support both versions.


Benefits of OAuth 2.0

To have a glimpse into the benefits, without going technical (which is the point in the next chapters), several scenarios follow.

API security

Imagine an enterprise providing an API for some customers (be it RESTful, SOAP-based, and so on). In order to make it secure and to have regulated access to it, one way is to use the so called basic authentication, where the username and password are sent using Base64 encoding—but not encoded or hashed—and SSL is used to secure the data transfer. The drawback here is that, in this type of authentication, the user, alongside his username, enters and sends his password over the wire as well.

What can be improved? In order to secure the API with OAuth 2.0, every time a request is made to the API, instead of username and password, an access token is sent. This token is obtained by the client application before making the requests, and represents the user on whose behalf the client application is using the API.

Related scenario—a client application, which is using the API, starts misbehaving and uses it improperly. All that has to be done is to revoke the access token, making all future requests invalid (if they are made with the same token).

Another important thing to note is that the access token can be set on how much access to have, which is called scope. So a client application may not have full API access when using access tokens. In contrast, if the client application was using username and password instead of access tokens, and these credentials were stolen, the whole API could be misused until the hijacked account is blocked.

Internal enterprise applications

Next, imagine a company utilizing a set of enterprise applications that are used internally. Company employees have to enter username and password manually in every separate application. This poses a security risk in several areas; there are several databases storing passwords, passwords are more often sent over, and so on.

With OAuth 2.0 what can be done is to have one application where the user logs in with his username and password (the OAuth 2.0 based service provider), and in all the other applications he is simply redirected to the provider where he logged in and confirms that he wants to be authorized. This way, instead of storing passwords these applications are storing the tokens for the users. The benefit is that when a password is stolen, the user has to reset his password, compared to when a token is stolen and it is revoked (invalidated).

Another related scenario is security in BYOD (bring your own device) companies. If a user brings his smartphone and uses an internal company application on it, and this smartphone gets stolen or compromised, the password of the user won't be exposed and only the tokens that were in use will have to be invalidated. The user can get a new device, and when he authorizes it he will get a new token.

Service integration and authorization delegation

Imagine that a user has an account on a photo sharing service, and also on a print ordering service.

If these two services have OAuth 2.0 integration between them, the user can authorize the printing service to access resources from the photo sharing service on his behalf. For example, the user would log in to the photo sharing service, then would log in to the printing service and request the integration, after which the user is redirected back to the photo sharing service, where he approves the authorization request.

From this point on, the printing service has an access token on behalf of this user, and can be aware which photos the user has uploaded. And the user can access the photos on the printing service without re-uploading them again there, but retrieved via the photo sharing service.

The best part of it is that the user hasn't given the username and password combination to the printing service, but instead the printing service has received an access token when it was authorized by the user.

This shows one of the key strengths of using OAuth 2.0—authorization delegation. With OAuth 2.0 you can give access to your data/resources on some service to another one, and easily revoke this access when you change your mind. This applies everywhere, from internal enterprise applications to various services such as social media applications.

Federated identity

Another key strength of OAuth 2.0 is federated identity.

With federated identity, a person's digital identity and details (such as e-mail, name and surname, and gender) can be linked between several distinct services.

The previous two examples show this, but let's see another example; users can log in to one OAuth 2.0 provider (for example, Facebook or LinkedIn) and then log into other web services via this provider, without entering new username and password. For example, a user wants to leave a comment on some blog post and needs to be identified in order for the comment to be accepted.

This case is also known as using OAuth 2.0 for authentication. The client application (for example, the blogging platform) is requesting only the user's information after it got authorized and nothing more.

Easier service monitoring

Last but not least, enterprises can track and monitor more easily which access token is making which request; based on this they can make calculations and gain better insight about which services are used more often by its clients, and make optimizations.



In this chapter, we have learned what OAuth 2.0 is, what purpose it has, why it was created, and what the benefits of using it are.

In the next chapter, we will define and explain all key terms that are part of the OAuth 2.0 protocol.

About the Author

  • Martin Spasovski

    Martin Spasovski is a software development professional involved in developing JVM-based enterprise solutions. He has been working with various back-end technologies and architectures, and with various front-end technologies (from RCP to modern JavaScript web applications), and knows how to integrate both sides well. He mostly likes to work in the domain of data processing, software optimization, and providing custom solutions. He is a vocal open source and open standards supporter, and a member of the local Java User Group named JUGMK, and likes to research on emerging technologies and give internal presentations at Seavus, the company that he works for. He can be found at http://thisismartin.com, where his blog, contact info, and links to public project repositories can be found.

    Browse publications by this author

Latest Reviews

(2 reviews total)
Compra simples e direta. Estou muito satisfeito.

Recommended For You

Book Title
Access this book and the full library for FREE
Access now