OAuth2 Implementation Presentation (Java)

knoldus 173 views 21 slides May 13, 2024
Slide 1
Slide 1 of 21
Slide 1
1
Slide 2
2
Slide 3
3
Slide 4
4
Slide 5
5
Slide 6
6
Slide 7
7
Slide 8
8
Slide 9
9
Slide 10
10
Slide 11
11
Slide 12
12
Slide 13
13
Slide 14
14
Slide 15
15
Slide 16
16
Slide 17
17
Slide 18
18
Slide 19
19
Slide 20
20
Slide 21
21

About This Presentation

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 authenti...


Slide Content

OAuth2 Implementation Presented By – Aasif Ali

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.

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

Introduction to OAuth 2

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.

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.

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

OAuth 2 Roles  02

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.

OAuth 2 Grant Types 03

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.

Authorization Process 04

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. 

A typical use-case

How It Works: The Building Blocks of OAuth 2.0 05

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.

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.

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.

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.

Setting up OAuth 2 in Spring Boot: Demo Example 06
Tags