Open Authorization(OAuth) 2.0

1. Overview

• OAuth is an open standard protocol for authentication
• External service functions can be used in other applications
• OAuth2.0 is not compatible with 1.0, but the authentication process is simple

1.1 Difference between OAuth and Login

• Login is when a member of the A service uses the A service
• In the case of OAuth, the B service performs authentication and authentication through the method provided by A in order to partially use the functions of the A service
• Service B can use some functions of service that provides OAuth through OAuth
• For example, in the case of OAuth through Facebook, you can use the API provided by Facebook (write feed, call friend list, etc.)

1.2 Components

• Resource Owner: Be the owner of various information and generally use the service
• Client: Here, the Client uses OAuth. In other words, it becomes my application
• Authorization Server: The third server in charge of authentication and authorization procedures
• Resource Server: It is a subject that provides protected information desired by the client through the use of OAuth

1.3 Simple Process

• We have to go through the process of "authentication" and "authorization" through the Authorization Server with the information from the user
• During this process, the client receives the Credential/ Authorization Code from the Authorization Server
• Client issues AccessToken through the corresponding code
• Through AccessToken, Client gets permission to Access Resource
• AccessToken expires after a certain period of time, and we receive a new AccessToken through RefreshToken

1.4 Changes

	1.0a	2.0
User	User	Resource Owner
Client	Consumer	Client
API Server	Service Provider	Resource Server
Authorization Server		Authorization Server
Use Case	Twitter, Vimeo, NAVER, NETFLIX, tumblr., YAHOO!	Facebook, foursquare, Instagram, Google, Tistory

1.5 Advantages of OAuth 2.0

• Simplicity
• Scalability
  • No need to manage various device format
  • No concern about CORS and LB
• Stateless
  • No Session to sustain
  • No burden of persisting large session
• Security
  • signature -> HTTPS
• Extensibility
  • Log in rocketpunch with Facebook, LinkedIn, GitHub, and Google Account.

1.6 Purpose of OAuth 2.0

1.6.1 Federated identity

OAuth 2.0 allows users to log in to the application with their other accounts. For example, if you log in to Github with a Google account, that user only needs to manage one Google account. In this sense, it can be said that multiple sites are united and use a single user identity.

1.6.2 Delegated authority

OAuth 2.0 allows you to access the resources of another service on your behalf. For example, if you look at a Google user's contact list on LinkedIn and recommend that people in that contact register as LinkedIn friends. This means that LinkedIn has been delegated the right to access your Google contact list. In fact, Federated identity and Delegated authority are strictly the same. In both cases, you are accessing a protected resource on behalf of the resource owner.

2. Components

2.1 Roles

2.1.1 Resource Owner

• User

2.1.2 Resource Server

• Server hosting protected data
• Facebook API, Firebase API, etc.

2.1.3 Client

• An application requesting access to a resource server
• Frontend web site, mobile application, etc.

2.1.4 Authorization Server

• Server issuing access token to the client
• Able to be the same as the authorization server
  • Same physical server
  • Same application

2.2 Tokens

2.2.1 Access Token

• Allowing the user data from being accessed by a third-party application
• Attached in the header of a request
• Limited lifetime
• Must be kept confidential as soon as possible
  • Not always possible, especially when the client is a web browser that sends requests to the resource server via javascript

2.2.2 Refresh Token

• Issued with an access token
• Being sent to the authorization server for renewing the access token when it has expired.
• Not possible always to obtain this token for security reasons

2.3 Access token scope

• A parameter used to limit the rights of the access token. Authorization server defines the list of the available scopes.
• The client must send the scopes he wants to use for his application during the request to the authorization server.

2.4 Register as a client

• To retrieve data from a resource server using OAuth2, have to register as a client of the authorization server
• Client registration
  • Application Name: The application name
  • Redirect URLs: URLs of the client for receiving authorization code and access token
  • Grant Type: authorization types that will be used by the client
  • Javascript Origin(optional): the hostname that will be allowed to request the resource server via XMLHttpRequest

2.5 Authorization server response

• Client Id: a unique random string
• Client Secret: a secret key that must be kept confidential

3. Client types and Authorization grant types

3.1 Client types

The criterion is whether the client secret can be safely stored.

3.1.1 Public Client

• No client secret
• Devices owned by Resource Owner
• Such as Phone, Javascript Application

3.1.2 Confidential Client

• Store client secret
• Devices that can store client secret safely
• Such as Server

3.2 Authorization grant types

• Authorization Code Grant
• Implicit Grant
• Resource Owner Password Credential Grant
• Client Credentials Grant

	2-legged	3-legged
Public Client	Password Credential Grant	Implicit Grant
Confidential Client	Client Credentials Grant	Authorization Code Grant

3.2.1 2-legged Usages

• Smart TV
• No-browser device
• Server

3.1 Authorization Code Grant

Authorization Code allows the Resource Owner to authenticate and authorize on the Authorization Server, rather than the Client requesting authorization directly from the Resource Owner. When the owner grants permission, an Authoriztion Code is issued and this Authorization Code is delivered to the client. The client sends this code to the authorization server, notifying that is has been granted authorization and receiving an access token. This method has security advantages. Since the access token is not delivered directly to the client, it helps to prevent potential leakage risks that may occur during the delivery process.

3.1.1 When to use

• Should be used as soon as the client is a web server.
• Allows you to obtain a long-lived access token since it can be renewed with a refresh token if authorization server enable it

3.1.2 Example

• Resource Owner: you
• Resource Server: a Google server
• Client: any website
• Authorization Server: a Google server

3.1.3 Scenario

• A website wants to obtain information about your Google profile
• You are redirected by the client(the website) to the authorization server(Google).
• If you authorize access, the authorization server sends an authorization code to the client(the website) in the callback response.
• Then, this code is exchanged against an access token between the client and the authorization server.
• The website is now able to use this access token to query the resource server(Google) and retrieve your profile data.

3.2 Implicit Grant

Implicit is a simplified procedure for Authorization Code. Unlike the Authorization Code that used the Authorization Oce as an intermediary to obtain an access token, in this method, the Authorization Code is not separately issued and access token is issued immediately. Less processes make it easier but less security.

3.2.1 When to use

• Typically used when the client is running in a browser using a scripting language such as javascript
• Does not allow the issuance of a refresh token

3.2.2 Example

• Resource Owner: you
• Resource Server: a Facebook server
• Client: a website using AngularJS for example
• Authorization Server: a Facebook server

3.2.3 Scenario

• The client(AngularJS) wants to obtain information about your Facebook profile.
• You are redirected by the browser to the authorization server(Facebook)
• If you authorize access, the authorization server redirects you to the website with the access token in the URI fragment(not sent to the webserver).
  • http://example.com/oauthcallback#access_token=MzJmNDc3M2VjMmQzN
• This access token can be retrieved and used by the client (AngularJS) to query the resource server(Facebook)
  • https://graph.facebook.com/me?access_token=MzJmNDc3M2VjMmQzN

It's possible thanks to a header called Access-Control-Allow-Origin present in the response in spite of the Same Origin Policy.

3.3 Resource Owner Password Credentials Grant

In this method, account authentication information such as the resource owner's account ID and password is used as an Authorization Grant to obtain an access token. Account information must be entered directly into the application, so it must be trusted. After obtaining the access token, it is not necessary for the client to keep the account ID and password for resource requests.

3.3.1 When to use

The credentials are sent to the client and then to the authorization server. It is mainly used when the client has been developed by the same authority as the authorization server. 

3.3.2 Example

• Resource owner: You
• Resource Server: KAKAO(KAKAO API)
• Client: acme.com website from Acme company
• Authorization server: KAKAO Server

3.3.3 Scenario

• KAKAO thought to make available a RESTful API to third-party applications.
• KAKAO thinks it would be convenient to use its own API to avoid reinventing the wheel.
• KAKAO needs an access token to call the methods of its own API. 
• For this, KAKAO asks you to enter your login credentials via a standard HTML form as you normally would.
• The server-side application will exchange your credentials against an access token from the authorization server if your credentials are valid
• This application can now use the access token to query its own resource server

3.4 Client Credentials Grant

This method is also referred to as the client authentication method. This method is used in situations where the resource owner is the client, not the user. This can be used when access is limited to the resources managed by the Client. In other words, it is a situation in which the Client soon becomes the Resource Owner. The client requests an access token while sending information that can authenticate itself to the Authorization Server.

3.4.1 When to use

Used when the client is himself the resource owner. No authorization to obtain from the end-user

3.4.2 Example

• Resource Owner: any website
• Resource Server: Google Cloud Storage
• Client: the resource owner
• Authorization Server: a Google server

3.4.3 Scenario

• A website stores its files of any kind on Google Cloud Storage
• The website must go through the Google API to retrieve or modify files and must authenticate with the authorization server.
• Once authenticated, the website obtains an access token that can now be used for querying the resource server(Google Cloud Storage)

4. Which to use

Grant Type	Good for
Implicit	Untrusted SPA apps like Angular, React, Vue.js
Authorization Code with PKCE	Untrusted Native or Mobile apps. PKCE = Proof Key Code Exchange
Authorization Code	A trusted app like Spring boot or .NET
Client Credentials	Trusted batch or automated apps without Resource Owner like a cron job
Resource Owner Password	Trusted web apps with custom login page

5. Access token usage

5.1 Request parameter

• https://api.example.com/profile?access_token=MzJmNDc3M2VjMmQzN
• This is not ideal because the token can be found in the access logs of the webserver

5.2 Authorization header

• Authorization: Bearer MzJmNDc3M2VjMmQzN
• Elegant but all resource servers do not allow this

6. Security

6.1 Authorization Code Grant

• Cross-site Request Forgery
• Workaround
  • To prevent it, attaching unique random hash to verify when it comes back

5.2 Vulnerability in Implicit Grant

• Cross-site Request Forgery
• Workaround
  • Provide in its API a way to retrieve access token information to compare the client_id of the access token of the attacker against its own client_id

6.3 Clickjacking

• To cheat by hiding the authorization page in a transparent iframe and getting the victim to click a link that is visually over the "Allow" button of the authorization page.

6.4 workaround

• The authorization server returns a header named X-Frame-Options on the authorization page with the value DENY or SAMEORIGIN.

7. Validation

The resource server validates the signature using the following information:

• Client
• Lifetime
• Scopes
• Roles

8. Comparison between OAuth 2.0 and JWT

 

9. Combining OAuth and JWT

10. References

https://www.ubisecure.com/uncategorized/difference-between-saml-and-oauth/

https://www.tutorialspoint.com/oauth2.0/oauth2.0_overview.htm

https://tansfil.tistory.com/60

https://www.loginradius.com/engineering/blog/using-jwt-with-oauth2-when-and-why/

https://capgemini.github.io/architecture/combining-oauth-and-jwt-to-gain-performance-improvements/

https://dzone.com/articles/whats-better-oauth-access-tokens-or-json-web-token

https://www.oauth.com/oauth2-servers/access-tokens/self-encoded-access-tokens/

https://nordicapis.com/why-cant-i-just-send-jwts-without-oauth/

https://www.it-swarm.dev/ko/oauth/oauth-20-%EC%9D%B4%EC%A0%90-%EB%B0%8F-%EC%82%AC%EC%9A%A9-%EC%82%AC%EB%A1%80-%E2%80%93-%EC%99%9C/940165903/

https://www.sauru.so/blog/basic-of-oauth2-and-jwt/

http://blog.weirdx.io/post/39955

https://interconnection.tistory.com/76

http://prokuma.kr/oauth/2016/08/04/what-is-oauth.html

https://www.slideshare.net/tebica/oauth2-api

https://velog.io/@minholee_93/OAuth2.0-z0k4ajksyw

https://real-dongsoo7.tistory.com/113

http://www.bubblecode.net/en/2016/01/22/understanding-oauth2/

https://www.ory.sh/oauth2-for-mobile-app-spa-browser/

https://hub.packtpub.com/what-is-the-difference-between-oauth-1-0-and-2-0/

https://developer.okta.com/blog/2018/12/13/oauth-2-for-native-and-mobile-apps