The OAuth 2.0 authorization framework is a protocol that allows a user to grant a third-party web site or application access to the user's protected resources, without necessarily revealing their long-term credentials or even their identity. It is commonly used in scenarios such as user authentication in web and mobile applications and enables a more secure and user-friendly authorization process.

1. OAuth2 Implementation
Presented By – Aasif Ali

2. Lack of etiquette and manners is a huge turn off.
KnolX Etiquettes
 Punctuality
Join the session 5 minutes prior to the session start time. We start on
time and conclude on time!
 Feedback
Make sure to submit a constructive feedback for all sessions as it is very
helpful for the presenter.
 Silent Mode
Keep your mobile devices in silent mode, feel free to move out of session
in case you need to attend an urgent call.
 Avoid Disturbance
Avoid unwanted chit chat during the session.

3. 1. Introduction to OAuth 2.0
2. OAuth 2.0 Roles
3. OAuth 2.0 Grant Types
4. Authorization Process
5. How It Works: The Building Blocks of OAuth 2.0
6. Setting up OAuth 2 in Spring Boot: Demo Example

5. What is Authorization
 Authorization is the process of determining whether an authenticated user or client has the necessary
permissions to access a specific resource or perform a particular action within a system or application.
 "Are you allowed to do this?"
 It ensures that only authorized users or clients can access certain data or functionalities, protecting sensitive
information and maintaining the security of the system.

6. What is OAuth 2?
 OAuth 2.0 (Open Authorization 2.0) is an authorization framework that enables third-party applications
to access resources on behalf of a resource owner (user), with the resource owner's permission.
 It is widely used for securing APIs and enabling secure access to protected resources on the web.
 OAuth 2.0 is an evolution of OAuth 1.0, offering improvements in security, simplicity, and flexibility.
 OAuth 2.0 provides consented access and restricts actions of what the client app can perform on
resources on behalf of the user, without ever sharing the user's credentials.
 OAuth 2.0 is an authorization protocol and NOT an authentication protocol. As such, it is designed
primarily as a means of granting access to a set of resources, for example, remote APIs or user data.

7. OAuth1 vs OAuth2
 Complexity: More complex and difficult to
implement due to cryptographic requirements.
 Token Type: Uses both request and access
tokens.
 Signature: Requests are signed for verification,
ensuring authenticity.
OAuth1
 Simplicity: Simpler and more streamlined
compared to OAuth 1.
 Token Type: Utilizes only access tokens.
 Scalability: More scalable, supporting a wider
range of use cases.
OAuth2

8. 02

9. Resource Owner
 An entity capable of
granting access to a
protected resource.
Typically, this is the
end-user.
OAuth 2 Roles
Client
 An application requesting
access to a protected
resource on behalf of the
resource owner.
 To access resources, the
Client must hold the
appropriate Access
Token.
Authorization Server
 The server that
authenticates the
resource owner and
issues access tokens
after obtaining
authorization.
Resource Server
 The server hosting the
protected resources,
capable of accepting
and responding to
requests using access
tokens.

10. 03

11. Authorization Code
 The authorization code grant type is widely used for server-side applications, ensuring Client Secret
confidentiality. It involves redirection, where the app communicates with the user's browser to receive
authorization codes.
OAuth 2 Grant Types
Implicit
 A simplified flow where the Access Token is returned directly to the Client. In the Implicit flow, the authorization
server may return the Access Token as a parameter in the callback URI or as a response to a form post.
Resource Owner Password Credentials
 This grant requires the Client first to acquire the resource owner’s credentials, which are passed to the
Authorization server. Allows users to provide their credentials directly to the application, which then exchanges
them for an access token. It's useful for trusted applications like native mobile apps.
Client Credentials
 Used for non-interactive applications e.g., automated processes, microservices, etc. It allows a client to request
an access token using the resource owner's username and password directly, rather than going through an
authorization process with redirects.

12. 04

13. Authorization Process
 The Client requests authorization (authorization request) from the Authorization server, supplying the client
id and secret to as identification; it also provides the scopes and an endpoint URI (redirect URI) to send the
Access Token or the Authorization Code to.
 The Authorization server authenticates the Client and verifies that the requested scopes are permitted.
 The Resource owner interacts with the Authorization server to grant access.
 The Authorization server redirects back to the Client with either an Authorization Code or Access Token,
depending on the grant type.
 With the Access Token, the Client requests access to the resource from the Resource server.

14. A typical use-case

15. 05

16. Scopes and Consent
 Scopes are mechanisms that define permissions and set boundaries for what an application or service
does or does not have access to.
 When an app sends an authorization request, the user is presented with the specific scope of the request
and must authorize consent.
 This consent serves as proof of authorization and allows an access token to be granted.

17. Actors
 The resource owner owns the data for which access is requested. The resource owner can be an individual
end-user or a company.
 The resource server is the API or server that securely stores the data the application or service has
requested to access. The resource server must accept and validate an access token from the requesting
application to grant access to the data.
 The client is the application or service requesting access to the data the resource server is protecting.
Clients gain access to the requested resources by presenting a valid access token to the resource server.
 The authorization server handles token management. It manages tokens, which are like keys to access
resources. When a client wants access to something, like your photos, it asks the authorization server.
Once you say yes, the server gives the client a new access token, like a special key, to use on the
resource server.

18. Clients
 Confidential clients keep secrets and operate in secure areas inaccessible to end-users.
 Public clients, on the other hand, are less secure and include browsers, mobile apps, and IoT devices.

19. Tokens
 Access tokens are granted by the authorization server and used to access the data in the
resource server. They typically allow clients to access resources for a few minutes up to a few
hours.
 Refresh tokens are only granted to confidential clients with secure authentication protocols
and can be valid for days, months, or even years - they can also be used to get new access
tokens for other clients.

20. 06