Skip to content

oauth-2.0-basics.md

Latest commit

 

History

History
66 lines (40 loc) · 4.38 KB

oauth-2.0-basics.md

File metadata and controls

66 lines (40 loc) · 4.38 KB
Raw

OAuth 2.0 Basics

Common Usage of OAuth 2.0:

  • OAuth 2.0 is a widely used authorization framework allowing websites to request limited access to a user's account on another application.
  • It facilitates access without exposing login credentials, letting users control the data they share.

Three Main Parties:

  • Client Application: Requests user data.
  • Resource Owner: User whose data is requested.
  • OAuth Service Provider: Controls user data and provides APIs for authorization and resource servers.

Elements in OAuth 2.0:

  • Resource Owner: User granting access to protected resources
  • User-Agent: The browser or mobile application through which the resource owner communicates with our authorization server.
  • Resource Server: Server handling authenticated requests
  • Client Application: The application that seeks access to resources.
  • Authorization Server: Server issuing access tokens after authentication (e.g., twitter.com).
  • Client_id & Client_secret: Identifiers for the application, with the secret known only to the app and authorization server.
  • Response_type: Specifies the type of token requested (e.g., code).
  • Scope: Defines the level of access requested.
  • Redirect_uri: URL for user redirection after authorization.
  • State: CSRF protection mechanism.
  • Grant_type: Explains the grant type for token retrieval.
  • Code & Access_token: A token which is issued as a result of successful authorization. An access token can be obtained for a set of permissions (scopes) and has a pre-determined lifetime after which it expires..
  • Refresh_token: Allows obtaining a new access token without user prompt.

OAuth 2.0 Flows (Grant Types):

https://www.youtube.com/watch?v=ZDuRmhLSLOY

This flow is optimized for confidential clients. Confidential clients are apps that can guarantee the secrecy of client_secret. A part of this flow happens in the front-channel (until the authorization code is obtained). As you can see, the access_token 🔑 exchange step happens confidentially via back-channel (server-to-server communication).

  • Authorization Code Grant with PKCE

  • Client Credentials Grant flow

    a resource owner (user) had to provide consent. There can also be scenarios where a user's authorization is not required every time. Think of machine-to-machine communication (or app-to-app). In this case, the client is confidential by nature and the apps may need to act on behalf of themselves rather than that of the user.

  • Resource Owner Password Credentials Grant flow

  • Resource Owner Password Credentials Grant flow

  • Implicit Grant flow

    However, the token is passed in the URL fragment (Begins with #) which will never be sent over the network to the redirect URL. Instead, the fragment part is accessed by a script that is loaded in the front-end (as a result of redirection). The access_token will be extracted in this manner and subsequent calls are made to fetch the resources. As you can already see, this flow is susceptible to access token leakage and replay attacks

OAuth Authentication:

  • Although not originally intended for this purpose, OAuth has evolved into a means of authenticating users as well.
  • The "Authorization Code" grant type is commonly used for authentication in websites when implementing features like "Sign in with Google" or similar social login functionalities.