diff --git a/src/css/style.css b/src/css/style.css index 8ac19e6..33d6c23 100644 --- a/src/css/style.css +++ b/src/css/style.css @@ -234,6 +234,11 @@ pre { text-align: center; } +.y-colored { + color: #FF6600 !important; + font-weight: bold; +} + @media screen and (max-width: 600px) { .page-header { font-size: 1.5rem; diff --git a/src/flow/code-2.html b/src/flow/code-2.html index 1098750..ae323b5 100644 --- a/src/flow/code-2.html +++ b/src/flow/code-2.html @@ -1,5 +1,6 @@ + @@ -11,14 +12,14 @@ - + +
@@ -56,25 +57,33 @@
2. Verify the state parameter
-

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:

+

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

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

  • code=

    -

    The code parameter contains the actual authorization code. This is a temporary code that the client can exchange for an - access token (and optionally, a refresh token) by making a back-channel request to the Authorization Server. - The format and structure of the code is determined by the Authorization Server. It can be just a random string, or a more complex construction. The exact significance of this structure is specific to the Authorization Server implementation and might include different identifiers or information encoded in - the structure.

    +

    + The code parameter contains the actual authorization code. This is a temporary code that the client can exchange for an + access token (and optionally, a refresh token) by making a back-channel request to the Authorization Server. + The format and structure of the code is determined by the Authorization Server. It can be just a random string, or a more complex construction. The exact significance of this structure is specific to the Authorization Server implementation and might include different identifiers or information encoded in + the structure. +

-

Now we have everything necessary to obtain token for the user. But is the state we have sent () equivalent to the one we received back ()?

+

+ Now we have everything necessary to obtain token for the user. But is the state we have sent () equivalent to the one we received back ()? +

States are matching @@ -117,4 +126,4 @@ } - + \ No newline at end of file diff --git a/src/flow/code-3.html b/src/flow/code-3.html index 0fd7bae..d22ad42 100644 --- a/src/flow/code-3.html +++ b/src/flow/code-3.html @@ -1,5 +1,6 @@ + @@ -11,14 +12,14 @@ - + +
@@ -72,9 +73,10 @@

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

    +

    + 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=

    @@ -82,13 +84,11 @@

  • code=

    -

    This is the authorization code we got in the previous step and is used to obtain the - access token.

    +

    This is the authorization code we got in the previous step and is used to obtain the access token.

    • - Get access token + Get access token
    @@ -106,43 +106,45 @@

    • token_type

      -

      Indicates the type of token issued. In OAuth 2.0, the common type is "Bearer", which means that whoever bears - the token - can access the resources.

      +

      + Indicates the type of token issued. In OAuth 2.0, the common type is "Bearer", which means that whoever bears + the token can access the resources. +

    • expires_in

      -

      Indicates the number of seconds for which the access_token is valid. After this time, the access_token - will expire and a - new one must be obtained.

      +

      + Indicates the number of seconds for which the access_token is valid. After this time, the access_token + will expire and a new one must be obtained. +

    • 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.). +

      + 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.).

    • refresh_token

      -

      Used to obtain a new access_token when the current one expires. This allows the client to get a new - access_token without - requiring the user to log in again. +

      + Used to obtain a new access_token when the current one expires. This allows the client to get a new + access_token without requiring the user to log in again.

    • scope

      -

      Specifies the scopes granted by the user to the client application. Scopes determine the permissions - associated with the - access_token. Here, the granted scopes are email, offline_access, and profile. This means that with - the provided access_token, the - client application can access the user's email and profile information and is also granted offline access - (typically - used in conjunction with refresh tokens). +

      + Specifies the scopes granted by the user to the client application. Scopes determine the permissions + associated with the access_token. Here, the granted scopes are email, offline_access, and profile. This means that with + the provided access_token, the client application can access the user's email and profile information and is also granted offline access + (typically used in conjunction with refresh tokens).

    -

    And this concludes the Authorization Code Flow. Client application would now be able to request resources on users behalf without having to transfer his credentials with each request.

    +

    + And this concludes the Authorization Code Flow. Client application would now be able to request resources on users behalf without having to transfer his credentials with each request. +

    Try different flow
    @@ -218,4 +220,4 @@ fillRequestExample(); - + \ No newline at end of file diff --git a/src/flow/code.html b/src/flow/code.html index bf97ac3..19d22ca 100644 --- a/src/flow/code.html +++ b/src/flow/code.html @@ -1,5 +1,6 @@ + @@ -11,14 +12,14 @@ - + +
    @@ -64,51 +65,60 @@

    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.). +

      +

      + 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 Authorization Code flow, so - we are requesting the authorization code.

      +

      + OAuth 2.0 response type. In this case, we are using the Authorization Code flow, so + we are requesting the authorization code. +

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

      +

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

      +

      + 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 +

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

      + 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).

      +

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

    +

    + 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 + Authenticate
    @@ -153,6 +163,8 @@ $("#redirectUri").text(redirectUri); $("#scope").text(scope); $("#state").text(state); + + $("#sendRequestBtn").attr("href", constructRequestUrl()); } function getRedirectUri() { @@ -163,10 +175,9 @@ const redirectUri = getRedirectUri(); const scope = "offline_access"; const state = generateSessionState(); - setCookie("state", state, 5); + fillExample(); - $("#sendRequestBtn").attr("href", constructRequestUrl()); - + \ No newline at end of file diff --git a/src/flow/dag-2.html b/src/flow/dag-2.html index 97c1cec..d163aa3 100644 --- a/src/flow/dag-2.html +++ b/src/flow/dag-2.html @@ -1,5 +1,6 @@ + @@ -11,8 +12,7 @@ - + @@ -20,6 +20,7 @@ +
    @@ -73,21 +74,16 @@

    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. + used by the authorization server to identify the application when redirecting the user back to the client.

  • device_code=

    -

    - Device code we have obtained in the previous step. -

    +

    Device code we have obtained in the previous step.

    • -
    - Start polling + Start polling
    @@ -102,8 +98,9 @@
    3. Instruct the user where to enter the code
    -

    Device would typically show the user code on it's display (or in console output when connection to display-less device via SSH for example) and where possible, also the URL that the user should visit. Based on the capabilities the URL could be shown as a simple text, or QR code, or if the device didn't have display capable enough, than the URL could be written in a manual distributed with the device.

    - +

    + Device would typically show the user code on it's display (or in console output when connection to display-less device via SSH for example) and where possible, also the URL that the user should visit. Based on the capabilities the URL could be shown as a simple text, or QR code, or if the device didn't have display capable enough, than the URL could be written in a manual distributed with the device. +

    @@ -113,12 +110,12 @@
    - +
    -

    Now that we have the user code, we can for example scan a QR code and finalize this flow on our mobile device:

    @@ -143,50 +140,46 @@

    • token_type

      -

      Indicates the type of token issued. In OAuth 2.0, the common type is "Bearer", which means that whoever - bears - the token - can access the resources.

      +

      + Indicates the type of token issued. In OAuth 2.0, the common type is "Bearer", which means that whoever + bears the token can access the resources. +

    • expires_in

      -

      Indicates the number of seconds for which the access_token is valid. After this time, the - access_token - will expire and a - new one must be obtained.

      +

      + Indicates the number of seconds for which the access_token is valid. After this time, the + access_token will expire and a new one must be obtained. +

    • 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.). +

      + 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.).

    • refresh_token

      -

      Used to obtain a new access_token when the current one expires. This allows the client to get a - new - access_token without - requiring the user to log in again. +

      + Used to obtain a new access_token when the current one expires. This allows the client to get a + new access_token without requiring the user to log in again.

    • scope

      -

      Specifies the scopes granted by the user to the client application. Scopes determine the permissions - associated with the - access_token. Here, the granted scopes are email, offline_access, and profile. This means that - with - the provided access_token, the - client application can access the user's email and profile information and is also granted offline - access - (typically - used in conjunction with refresh tokens). +

      + Specifies the scopes granted by the user to the client application. Scopes determine the permissions + associated with the access_token. Here, the granted scopes are email, offline_access, and profile. This means that + with the provided access_token, the client application can access the user's email and profile information and is also granted offline + access (typically used in conjunction with refresh tokens).

    -

    And this concludes the Device Authorization Grant flow. Client application would now be able to request resources on - users behalf without having to transfer his credentials with each request.

    +

    + And this concludes the Device Authorization Grant flow. Client application would now be able to request resources on + users behalf without having to transfer his credentials with each request. +

    Try different flow
    @@ -329,4 +322,4 @@ fillExample(); - + \ No newline at end of file diff --git a/src/flow/dag.html b/src/flow/dag.html index be1ffc7..2bcaf10 100644 --- a/src/flow/dag.html +++ b/src/flow/dag.html @@ -1,5 +1,6 @@ + @@ -11,14 +12,14 @@ - + +
    @@ -57,15 +58,14 @@
    1. Request a Device Code

    - In order to initiate the Device Authorization Grant, we need to request a device code from the authorization server. The request is sent to the following URL: + In order to initiate the Device Authorization Grant, we need to request a device code from the authorization server. + The request is sent to the following URL:

    With body data:

    -
    - Get Device Code + Get Device Code
    @@ -177,4 +177,4 @@ fillExample(); - + \ No newline at end of file diff --git a/src/flow/expired.html b/src/flow/expired.html index b1ecec5..f666bf6 100644 --- a/src/flow/expired.html +++ b/src/flow/expired.html @@ -10,8 +10,7 @@ - + @@ -31,8 +30,7 @@ Flow could not continue as it was missing vital information. This can be caused by not performing the flow before codes and/or cookies expire, or by manually navigating to section of a flow, before finishing previous steps. Please start the flow again.

    - Start over + Start over
    @@ -44,5 +42,4 @@
    - \ No newline at end of file diff --git a/src/flow/pkce-2.html b/src/flow/pkce-2.html index 1e8e4e2..6ade4e6 100644 --- a/src/flow/pkce-2.html +++ b/src/flow/pkce-2.html @@ -11,8 +11,7 @@ - + @@ -63,67 +62,78 @@
    2. Build the Authorization URL
    -

    - First we need to build the authorization URL and redirect the user to the authorization server. The URL is constructed as follows: -

    +

    First 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 +

      +

      + 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 Authorization Code flow, so - we are requesting the authorization code.

      +

      + OAuth 2.0 response type. In this case, we are using the Authorization Code flow, so + we are requesting the authorization code. +

    • client_id=

      -

      Client ID of the application. This is a public identifier for the client, and it is +

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

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

      +

      + 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 +

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

      + 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).

      +

      + 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). +

    • code_challenge=

      -

      This is the code challenge we have created in the previous step. This ensures that even if an attacker intercepts the authorization code, they can't exchange it for an access token without the original code verifier.

      +

      + This is the code challenge we have created in the previous step. This ensures that even if an attacker intercepts the + authorization code, they can't exchange it for an access token without the original code verifier. +

    • code_challenge_method=

      -

      Code Challenge method tells the identity provider how the code_challenge was generated from the original code verifier. S256 means that - the challenge is a base64url encoding of the SHA-256 hash of the verifier. This is the recommended method for PKCE.

      +

      + Code Challenge method tells the identity provider how the code_challenge was generated from the original code + verifier. S256 means that the challenge is a base64url encoding of the SHA-256 hash of the verifier. This is the recommended method for PKCE. +

    -

    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.

    +

    + 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 + Authenticate
    diff --git a/src/flow/pkce-3.html b/src/flow/pkce-3.html index c38c9c7..1af7d09 100644 --- a/src/flow/pkce-3.html +++ b/src/flow/pkce-3.html @@ -1,5 +1,6 @@ + @@ -11,14 +12,14 @@ - + +
    @@ -63,34 +64,42 @@
    3. Verify the state parameter
    -

    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:

    +

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

      The state value isn't strictly necessary here since the PKCE parameters provide CSRF protection themselves. In practice, - if you're sure the OAuth server supports PKCE, you can use the state parameter for application state instead of using it - for CSRF protection.

      -

      +

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

      +

      + The state value isn't strictly necessary here since the PKCE parameters provide CSRF protection themselves. In practice, + if you're sure the OAuth server supports PKCE, you can use the state parameter for application state instead of using it + for CSRF protection. +

    • code=

      -

      The code parameter contains the actual authorization code. This is a temporary code that the client can exchange for an - access token (and optionally, a refresh token) by making a back-channel request to the Authorization Server. - The format and structure of the code is determined by the Authorization Server. It can be just a random string, or a more complex construction. The exact significance of this structure is specific to the Authorization Server implementation and might include different identifiers or information encoded in - the structure.

      +

      + The code parameter contains the actual authorization code. This is a temporary code that the client can exchange for an + access token (and optionally, a refresh token) by making a back-channel request to the Authorization Server. + The format and structure of the code is determined by the Authorization Server. It can be just a random string, or a more complex construction. The exact significance of this structure is specific to the Authorization Server implementation and might include different identifiers or information encoded in + the structure. +

    -

    Now we have everything necessary to obtain token for the user. But is the state we have sent () equivalent to the one we received back ()?

    +

    + Now we have everything necessary to obtain token for the user. But is the state we have sent () equivalent to + the one we received back ()? +

    - States are - matching + States are matching
    States are not matching @@ -130,4 +139,4 @@ } - + \ No newline at end of file diff --git a/src/flow/pkce-4.html b/src/flow/pkce-4.html index 24848e6..91270f7 100644 --- a/src/flow/pkce-4.html +++ b/src/flow/pkce-4.html @@ -1,5 +1,6 @@ + @@ -11,14 +12,14 @@ - + +
    @@ -79,9 +80,10 @@

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

    +

    + 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=

    @@ -89,20 +91,15 @@

  • code=

    -

    This is the authorization code we got in the previous step and is used to obtain the - access token. -

    +

    This is the authorization code we got in the previous step and is used to obtain the access token.

  • code_verifier=

    -

    This is the code verifier we generated in the first step. It is used to verify the - identity of the client. -

    +

    This is the code verifier we generated in the first step. It is used to verify the identity of the client.

    • - Get access token + Get access token
    @@ -120,42 +117,46 @@

    • token_type

      -

      Indicates the type of token issued. In OAuth 2.0, the common type is "Bearer", which means that whoever bears - the token - can access the resources.

      +

      + Indicates the type of token issued. In OAuth 2.0, the common type is "Bearer", which means that whoever bears + the token can access the resources. +

    • expires_in

      -

      Indicates the number of seconds for which the access_token is valid. After this time, the access_token - will expire and a - new one must be obtained.

      +

      + Indicates the number of seconds for which the access_token is valid. After this time, the access_token + will expire and a new one must be obtained. +

    • 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.). +

      + 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.).

    • refresh_token

      -

      Used to obtain a new access_token when the current one expires. This allows the client to get a new - access_token without - requiring the user to log in again.

      +

      + Used to obtain a new access_token when the current one expires. This allows the client to get a new + access_token without requiring the user to log in again. +

    • scope

      -

      Specifies the scopes granted by the user to the client application. Scopes determine the permissions - associated with the - access_token. Here, the granted scopes are email, offline_access, and profile. This means that with - the provided access_token, the - client application can access the user's email and profile information and is also granted offline access - (typically - used in conjunction with refresh tokens). +

      + Specifies the scopes granted by the user to the client application. Scopes determine the permissions + associated with the access_token. Here, the granted scopes are email, offline_access, and profile. This means that with + the provided access_token, the client application can access the user's email and profile information and is also granted offline access + (typically used in conjunction with refresh tokens).

    -

    And this concludes the Authorization Code Flow with PKCE. Client application would now be able to request resources on users behalf without having to transfer his credentials with each request.

    +

    + And this concludes the Authorization Code Flow with PKCE. Client application would now be able to request resources on users behalf without + having to transfer his credentials with each request. +

    Try different flow
    diff --git a/src/flow/pkce.html b/src/flow/pkce.html index 9d3b0c6..97ef8c6 100644 --- a/src/flow/pkce.html +++ b/src/flow/pkce.html @@ -1,5 +1,6 @@ + @@ -10,14 +11,14 @@ - + +
    @@ -62,7 +63,9 @@
    1. Create a Code Verifier and Challenge
    -

    Before we can start the authorization process, we need to create a code verifier and a code challenge. The code verifier is a cryptographically random string that is used to verify the identity of the client. The code challenge is a hashed version of the code verifier, which is sent to the authorization server. The authorization server will then compare the code challenge with the code verifier to verify the identity of the client.

    +

    + Before we can start the authorization process, we need to create a code verifier and a code challenge. The code verifier is a cryptographically random string that is used to verify the identity of the client. The code challenge is a hashed version of the code verifier, which is sent to the authorization server. The authorization server will then compare the code challenge with the code verifier to verify the identity of the client. +

    @@ -72,9 +75,10 @@
    - -

    Now that we habe the code verified, we need to create the code challenge. We do so by hashing the code verifier using the SHA256 algorithm and then encoding it using the URL-safe Base64 encoding.

    - +

    + Now that we habe the code verified, we need to create the code challenge. We do so by hashing the code verifier using the SHA256 algorithm and + then encoding it using the URL-safe Base64 encoding. +

    Generate Code Challenge
    @@ -83,12 +87,10 @@
    -

    Now that we have the code verifier and code challenge, we can start the authorization process.

    - Continue + Continue
    @@ -124,10 +126,7 @@ const verifier = $('#codeVerifier').val(); const encoder = new TextEncoder(); const data = encoder.encode(verifier); - const digest = await crypto.subtle.digest('SHA-256', data); - - // Convert hash to Base64 URL encoded string const base64UrlEncoded = btoa(String.fromCharCode(...new Uint8Array(digest))) .replace('+', '-') .replace('/', '_') @@ -140,5 +139,4 @@ } - \ No newline at end of file diff --git a/src/flow/webauthn-2.html b/src/flow/webauthn-2.html index 5fc159c..f87fcaf 100644 --- a/src/flow/webauthn-2.html +++ b/src/flow/webauthn-2.html @@ -1,5 +1,6 @@ + @@ -11,14 +12,14 @@ - + +
    @@ -56,25 +57,34 @@
    2. Verify the state parameter
    -

    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:

    +

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

      +

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

    • code=

      -

      The code parameter contains the actual authorization code. This is a temporary code that the client can exchange for an - access token (and optionally, a refresh token) by making a back-channel request to the Authorization Server. - The format and structure of the code is determined by the Authorization Server. It can be just a random string, or a more complex construction. The exact significance of this structure is specific to the Authorization Server implementation and might include different identifiers or information encoded in - the structure.

      +

      + The code parameter contains the actual authorization code. This is a temporary code that the client can exchange for an + access token (and optionally, a refresh token) by making a back-channel request to the Authorization Server. + The format and structure of the code is determined by the Authorization Server. It can be just a random string, or a more complex construction. The exact significance of this structure is specific to the Authorization Server implementation and might include different identifiers or information encoded in + the structure. +

    -

    Now we have everything necessary to obtain token for the user. But is the state we have sent () equivalent to the one we received back ()?

    +

    + Now we have everything necessary to obtain token for the user. But is the state we have sent () equivalent to the one we received back ()? +

    States are matching @@ -117,4 +127,4 @@ } - + \ No newline at end of file diff --git a/src/flow/webauthn-3.html b/src/flow/webauthn-3.html index 511ca37..f0fdb5c 100644 --- a/src/flow/webauthn-3.html +++ b/src/flow/webauthn-3.html @@ -1,5 +1,6 @@ + @@ -11,14 +12,14 @@ - + +
    @@ -72,9 +73,10 @@

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

    +

    + 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=

    @@ -82,13 +84,11 @@

  • code=

    -

    This is the authorization code we got in the previous step and is used to obtain the - access token.

    +

    This is the authorization code we got in the previous step and is used to obtain the access token.

    • - Get access token + Get access token
    @@ -106,43 +106,46 @@

    • token_type

      -

      Indicates the type of token issued. In OAuth 2.0, the common type is "Bearer", which means that whoever bears - the token - can access the resources.

      +

      + Indicates the type of token issued. In OAuth 2.0, the common type is "Bearer", which means that whoever bears + the token can access the resources. +

    • expires_in

      -

      Indicates the number of seconds for which the access_token is valid. After this time, the access_token - will expire and a - new one must be obtained.

      +

      + Indicates the number of seconds for which the access_token is valid. After this time, the access_token + will expire and a new one must be obtained. +

    • 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.). +

      + 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.).

    • refresh_token

      -

      Used to obtain a new access_token when the current one expires. This allows the client to get a new - access_token without - requiring the user to log in again. +

      + Used to obtain a new access_token when the current one expires. This allows the client to get a new + access_token without requiring the user to log in again.

    • scope

      -

      Specifies the scopes granted by the user to the client application. Scopes determine the permissions - associated with the - access_token. Here, the granted scopes are email, offline_access, and profile. This means that with - the provided access_token, the - client application can access the user's email and profile information and is also granted offline access - (typically - used in conjunction with refresh tokens). +

      + Specifies the scopes granted by the user to the client application. Scopes determine the permissions + associated with the access_token. Here, the granted scopes are email, offline_access, and profile. This means that with + the provided access_token, the client application can access the user's email and profile information and is also granted offline access + (typically used in conjunction with refresh tokens).

    -

    And this concludes the Authorization Code Flow. Client application would now be able to request resources on users behalf without having to transfer his credentials with each request.

    +

    + And this concludes the Authorization Code Flow. Client application would now be able to request resources on users behalf + without having to transfer his credentials with each request. +

    Try different flow
    @@ -218,4 +221,4 @@ fillRequestExample(); - + \ No newline at end of file diff --git a/src/flow/webauthn.html b/src/flow/webauthn.html index c9d25ef..6ac35b0 100644 --- a/src/flow/webauthn.html +++ b/src/flow/webauthn.html @@ -12,8 +12,7 @@ - + @@ -60,71 +59,65 @@
    1. Build the Authorization URL

    In order to initiate the WebAuthn, we proceed the same way as we would if we would be using Authorization Code Flow we need to build the - authorization URL - and redirect the user to the authorization server. All the passwordless logic is handled completely by the authorization server. The URL is constructed as - follows: + authorization URL and redirect the user to the authorization server. All the passwordless logic is handled completely by 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.). +

      +

      + 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 Authorization Code - flow, so - we are requesting the authorization code.

      -
      • -
    • -

      client_id= +

      response_type=

      +

      + OAuth 2.0 response type. In this case, we are using the Authorization Code + flow, so we are requesting the authorization code.

      -

      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 +

      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.

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

      +

      + 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 +

      + 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).

      + server and not a malicious third party (CSRF attack). +

    -

    All that we now need to do is click the button below and perform the Web Authentication Flow on the server. After your account will be 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.

    +

    + All that we now need to do is click the button below and perform the Web Authentication Flow on the server. After your account will be 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 + Authenticate
    @@ -141,8 +134,6 @@ - \ No newline at end of file diff --git a/src/index.html b/src/index.html index 50ba7d2..c465ec4 100644 --- a/src/index.html +++ b/src/index.html @@ -19,29 +19,28 @@ + -
    -
    +

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

    @@ -51,12 +50,14 @@
    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.

    +

    + 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 @@ -69,12 +70,14 @@
    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.

    +

    + 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 @@ -87,13 +90,15 @@
    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.

    +

    + 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 @@ -106,17 +111,14 @@
    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.

    +

    + 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 @@ -129,21 +131,15 @@
    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.

    +

    + 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 @@ -156,11 +152,13 @@
    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.

    +

    + 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 @@ -175,4 +173,4 @@
    - + \ No newline at end of file diff --git a/src/layout/footer.html b/src/layout/footer.html index 06faa51..1087621 100644 --- a/src/layout/footer.html +++ b/src/layout/footer.html @@ -4,27 +4,20 @@
    OAuth 2.0 Playground
    -

    This playground serves as an interactive platform designed to - familiarize developers and students with the +

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

    Links
    @@ -32,13 +25,10 @@
    © 2023 Y Soft Corporation ( - m0rsalis and - xRodney ) - Join us today! + m0rsalis and + xRodney ) + Join us today!
    -
    +
    \ No newline at end of file diff --git a/src/layout/header.html b/src/layout/header.html index 5b7c6e4..fea5871 100644 --- a/src/layout/header.html +++ b/src/layout/header.html @@ -2,7 +2,7 @@
    OAuth 2.0 Playground - by Y Soft + by Y Soft
    \ No newline at end of file