From 7f4a3490e78e1651fb686dbfb19d63b09fce8719 Mon Sep 17 00:00:00 2001 From: Dusan Jakub Date: Mon, 2 Oct 2023 12:37:10 +0200 Subject: [PATCH] Add: implicit flow --- src/flow/implicit-2.html | 118 +++++++++++++ src/flow/implicit.html | 176 ++++++++++++++++++++ src/index.html | 350 +++++++++++++++++++-------------------- 3 files changed, 469 insertions(+), 175 deletions(-) create mode 100644 src/flow/implicit-2.html create mode 100644 src/flow/implicit.html diff --git a/src/flow/implicit-2.html b/src/flow/implicit-2.html new file mode 100644 index 0000000..7cea2bd --- /dev/null +++ b/src/flow/implicit-2.html @@ -0,0 +1,118 @@ + + + + + + + OAuth 2.0 Playground - Authorization Code Flow (2/3) + + + + + + + + + + + + + + + +
+
+
+
+

Authorization Code Flow

+
+
+ 1 +
+
+
+ 2 +
+
+
+
+ Build the authorization URL and redirect the user to the authorization server +
+
+ User is redirected back with token in query +
+
+
+
+
+
+
+
+
2. Read token from query
+

+ You have now been redirected back to the application, to the page that was specified in the redirect-url parameter. + In the URL you can notice, that there are addtional query parameters: +

+
+

Let's break it down...

+
    +
  • +

    state=

    +

    + The state parameter is an opaque value used by the client to maintain state between the request and the callback. + Essentially, it is used to prevent Cross-Site Request Forgery (CSRF) attacks and to ensure the response belongs to the request made by the client. +

    +
    • +
  • +

    access_token=

    +

    + This is the actual access token, which allows the client application to access the user's protected resources + on the resource server (e.g., user profile, photos, etc.). +

    +
    • +
+

+ As the last thing, the client should verify that state we have sent () equivalent to the one we received back (). + If not, someone is tampering with us. +

+ +

+ And this concludes the Implicit Flow. +

+

+ Please be aware that by using the Implicit flow, you are making your application vulnerable to various attacks, which is why this flow is deprecated in OAuth 2.0 and removed in OAuth 2.1. +

+

+ Just use Authorization flow with PKCE everywhere you can. +

+
+ Try a different flow +
+
+
+
+
+
+
+ [ Take me home ] +
+
+
+ + + + + + \ No newline at end of file diff --git a/src/flow/implicit.html b/src/flow/implicit.html new file mode 100644 index 0000000..3eb52c2 --- /dev/null +++ b/src/flow/implicit.html @@ -0,0 +1,176 @@ + + + + + + + OAuth 2.0 Playground - Authorization Code Flow + + + + + + + + + + + + + + + +
+
+
+
+

Implicit Flow (deprecated)

+
+
+ 1 +
+
+
+ 2 +
+
+
+
+ Build the authorization URL and redirect the user to the authorization server +
+
+ User is redirected back with token in query +
+
+
+
+
+
+
+
+
1. Build the Authorization URL
+

+ In order to initiate the Authorization Code Flow, we need to build the authorization URL + and redirect the user to the authorization server. The URL is constructed as follows: +

+
+

Let's break it down...

+
    +
  • +

    +

    + URL of the authorization endpoint on the server. How is this path constructed will + differ between OAuth providers (such as Keycloak, Okta, etc.). +

    +
    • +
  • +

    response_type=

    +

    + OAuth 2.0 response type. In this case, we are using the Implicit flow, so + we are requesting the authorization token. +

    +
    • +
  • +

    client_id=

    +

    + Client ID of the application. This is a public identifier for the client, and it is + used by the authorization server to identify the application when redirecting the user back to the client. +

    +
    • +
  • +

    redirect_uri=

    +

    + Redirect URI of the client. This is the URL that the authorization server will + redirect the user back to after the user has logged in and granted permissions. + The redirect URI must match one of the URIs registered for the client ID. +

    +
    • +
  • +

    scope=

    +

    + Scopes requested by the client. Scopes are used to limit the access of the access + token. In this case, we are requesting the offline_access scope, + which allows the client to obtain a refresh token. +

    +
    • +
  • +

    state=

    +

    + State parameter. This is an optional parameter that the client can use to maintain + state between the request and callback. The authorization server includes this parameter when + redirecting the user back to the client, allowing the client to verify that the response is coming from the + server and not a malicious third party (CSRF attack). +

    +
    • +
+

+ All that we now need to do is click the button below and login with our credentials. + For the purposes of this playground we already took the liberty to create user with password user for you. + After your credentials are successfully verified, you will be redirected back to this playground, to the URL we have specified in + the redirect_uri query parameter of the request. +

+
+ Authenticate +
+
+
+
+
+
+
+ [ Take me home ] +
+
+
+ + + + + + + \ No newline at end of file diff --git a/src/index.html b/src/index.html index c465ec4..b1575e1 100644 --- a/src/index.html +++ b/src/index.html @@ -1,176 +1,176 @@ - - - - - - - OAuth 2.0 Playground - - - - - - - - - - - - - - - -
-
-
-
-

Welcome to OAuth 2.0 Playground

-

- This playground serves as an interactive platform designed to familiarize developers and students with the - intricacies of OAuth authentication processes. Beyond just theoretical knowledge, this playground provides practical - insights into the OAuth token exchange, - callback handling, and potential pitfalls or challenges one might face during real-world integrations. The ultimate aim - is to bolster - understanding and confidence in implementing OAuth, ensuring secure and efficient user authentication and authorization - in modern web applications. -

-

This project is an open-source initiative by Y Soft, as such we welcome any feedback or contributions at:

- -
-
-

Flows

-
-
-
-
-
-
-
Authorization Code Flow
-

- OAuth 2.0 protocol designed for web applications that can securely store client secrets. - The application directs users to an authorization server to log in and grant permissions. Upon consent, the server - issues an authorization code. The application then exchanges this code for an access token in a server-to-server - request, using its client ID, client secret, and redirection URI. This flow ensures the access token is never directly - exposed to users, offering enhanced security. It's best suited for server-side web applications with the capability to - protect the client secret. -

-
-
- Try it -
-
-
-
-
-
-
-
-
PKCE
-

- Proof Key for Code Exchange is a security protocol for the OAuth 2.0 authorization framework, designed to prevent - interception attacks in the authorization code flow. It's especially crucial for mobile or single-page applications - where storing a client secret securely is challenging. In PKCE, the client creates a dynamic "code verifier" and its - transformed "code challenge." The server remembers this challenge, and when the authorization code is exchanged for an - access token, the client provides the original verifier. The server validates it against the stored challenge, ensuring - added security against malicious interceptions. -

-
-
- Try it -
-
-
-
-
-
-
-
-
Device Authorization Grant
-

- OAuth 2.0 flow optimized for devices that either lack a browser or have limited input - capabilities, such as smart TVs, game consoles, and certain IoT devices. In this flow, the device makes a request to the - authorization server and receives a unique user code and a verification URL. The user then accesses this URL on a - separate device with a browser, like a smartphone or computer, and enters the user code. After successfully logging in - and providing consent, the device polls the authorization server to obtain an access token. This method ensures a - streamlined user experience for devices with restricted input or display capabilities, allowing them to access protected - resources without the need for intricate user interactions. -

-
-
- Try it -
-
-
-
-
-
-
-
-
WebAuthn
-

- This protocol leverages public key cryptography and allows users to authenticate using biometrics, mobile devices, or - FIDO security keys, instead of traditional passwords. When a user registers with a website, a unique key pair is - generated: the private key stays securely on the user's device, and the public key is registered with the website. For - subsequent logins, the website challenges the user to prove ownership of the private key, typically by prompting for a - biometric or a physical action on a security key. WebAuthn enhances user security by reducing reliance on easily - compromised passwords and defending against phishing attacks. -

-
-
- Try it -
-
-
-
-
-
-
-
-
CIBA
-

- Client Initiated Backchannel Authentication is a protocol extension for OAuth 2.0, tailored for scenarios where - the client, such as a financial institution or IoT device, initiates the authentication process without direct user - interaction on the client's platform. This is useful for "decoupled" authentication experiences, where, for instance, a - user might authenticate on their smartphone when prompted by a smart TV app. In CIBA, once the client requests - authentication, the authorization server prompts the user on a previously registered device, such as their mobile phone. - Upon successful authentication, the authorization server sends a token back to the client. This flow provides a seamless - and secure user experience, especially in contexts where traditional OAuth 2.0 interactions might be cumbersome or impractical. -

-
-
- build Under construction -
-
-
-
-
-
-
-
-
Implicit Flow
-

- OAuth 2.0 Implicit Flow was designed for browser-based applications where the client cannot maintain the confidentiality - of a secret. In this flow, after user authorization, the authorization server directly redirects the browser to the - client application with an access token in the URL fragment. However, this can expose tokens in browser history or logs, - making it less secure. Consequently, the use of Implicit Flow is being discouraged in favor of the more secure - Authorization Code Flow with PKCE in recent OAuth specifications. -

-
-
- build Under construction -
-
-
-
-
-
-
-
- - - + + + + + + + OAuth 2.0 Playground + + + + + + + + + + + + + + + +
+
+
+
+

Welcome to OAuth 2.0 Playground

+

+ This playground serves as an interactive platform designed to familiarize developers and students with the + intricacies of OAuth authentication processes. Beyond just theoretical knowledge, this playground provides practical + insights into the OAuth token exchange, + callback handling, and potential pitfalls or challenges one might face during real-world integrations. The ultimate aim + is to bolster + understanding and confidence in implementing OAuth, ensuring secure and efficient user authentication and authorization + in modern web applications. +

+

This project is an open-source initiative by Y Soft, as such we welcome any feedback or contributions at:

+ +
+
+

Flows

+
+
+
+
+
+
+
Authorization Code Flow
+

+ OAuth 2.0 protocol designed for web applications that can securely store client secrets. + The application directs users to an authorization server to log in and grant permissions. Upon consent, the server + issues an authorization code. The application then exchanges this code for an access token in a server-to-server + request, using its client ID, client secret, and redirection URI. This flow ensures the access token is never directly + exposed to users, offering enhanced security. It's best suited for server-side web applications with the capability to + protect the client secret. +

+
+
+ Try it +
+
+
+
+
+
+
+
+
PKCE
+

+ Proof Key for Code Exchange is a security protocol for the OAuth 2.0 authorization framework, designed to prevent + interception attacks in the authorization code flow. It's especially crucial for mobile or single-page applications + where storing a client secret securely is challenging. In PKCE, the client creates a dynamic "code verifier" and its + transformed "code challenge." The server remembers this challenge, and when the authorization code is exchanged for an + access token, the client provides the original verifier. The server validates it against the stored challenge, ensuring + added security against malicious interceptions. +

+
+
+ Try it +
+
+
+
+
+
+
+
+
Device Authorization Grant
+

+ OAuth 2.0 flow optimized for devices that either lack a browser or have limited input + capabilities, such as smart TVs, game consoles, and certain IoT devices. In this flow, the device makes a request to the + authorization server and receives a unique user code and a verification URL. The user then accesses this URL on a + separate device with a browser, like a smartphone or computer, and enters the user code. After successfully logging in + and providing consent, the device polls the authorization server to obtain an access token. This method ensures a + streamlined user experience for devices with restricted input or display capabilities, allowing them to access protected + resources without the need for intricate user interactions. +

+
+
+ Try it +
+
+
+
+
+
+
+
+
WebAuthn
+

+ This protocol leverages public key cryptography and allows users to authenticate using biometrics, mobile devices, or + FIDO security keys, instead of traditional passwords. When a user registers with a website, a unique key pair is + generated: the private key stays securely on the user's device, and the public key is registered with the website. For + subsequent logins, the website challenges the user to prove ownership of the private key, typically by prompting for a + biometric or a physical action on a security key. WebAuthn enhances user security by reducing reliance on easily + compromised passwords and defending against phishing attacks. +

+
+
+ Try it +
+
+
+
+
+
+
+
+
CIBA
+

+ Client Initiated Backchannel Authentication is a protocol extension for OAuth 2.0, tailored for scenarios where + the client, such as a financial institution or IoT device, initiates the authentication process without direct user + interaction on the client's platform. This is useful for "decoupled" authentication experiences, where, for instance, a + user might authenticate on their smartphone when prompted by a smart TV app. In CIBA, once the client requests + authentication, the authorization server prompts the user on a previously registered device, such as their mobile phone. + Upon successful authentication, the authorization server sends a token back to the client. This flow provides a seamless + and secure user experience, especially in contexts where traditional OAuth 2.0 interactions might be cumbersome or impractical. +

+
+
+ build Under construction +
+
+
+
+
+
+
+
+
Implicit Flow (deprecated)
+

+ OAuth 2.0 Implicit Flow was designed for browser-based applications where the client cannot maintain the confidentiality + of a secret. In this flow, after user authorization, the authorization server directly redirects the browser to the + client application with an access token in the URL fragment. However, this can expose tokens in browser history or logs, + making it less secure. Consequently, the use of Implicit Flow is being discouraged in favor of the more secure + Authorization Code Flow with PKCE in recent OAuth specifications. +

+
+
+ Try it +
+
+
+
+
+
+
+
+ + + \ No newline at end of file