diff --git a/src/flow/code-2.html b/src/flow/code-2.html index 879bdd7..d56c622 100644 --- a/src/flow/code-2.html +++ b/src/flow/code-2.html @@ -62,13 +62,6 @@ 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.

-
  • -

    session_state=

    -

    The session state parameter is not a core part of the OAuth 2.0 specification, but it is used in OpenID Connect (OIDC) - to represent the state of the end user's session at the Authorization Server. - The client can use this value to help manage user sessions or to detect when the user's session at the Authorization - Server changes (for example, if the user logs out).

    -
  • code=

    The code parameter contains the actual authorization code. This is a temporary code that the client can exchange for an @@ -100,10 +93,8 @@ const urlParams = new URLSearchParams(window.location.search); const code = urlParams.get('code'); const state = urlParams.get('state'); - const sessionState = urlParams.get('session_state'); $("#state").text(state); - $("#sessionState").text(sessionState); $("#code").text(code); function proceedToNextStep() { diff --git a/src/flow/code-3.html b/src/flow/code-3.html index 279255c..c2cedf2 100644 --- a/src/flow/code-3.html +++ b/src/flow/code-3.html @@ -101,50 +101,41 @@

    Let's break down what we have received...

    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.

    @@ -161,7 +152,7 @@ + + + + +
    +
    +
    +

    Device Authorization Grant

    +
    +
    + 1 +
    +
    +
    + 2 +
    +
    +
    + 3 +
    +
    +
    +
    + Request a device code from the authorization server +
    +
    + Instruct the user where to enter the code +
    +
    + Poll the authorization server periodically until the code has been successfully entered +
    +
    +
    +
    +
    +
    +
    +
    +
    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: +

    +
    +

    With body data:

    +
    +

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

      +
    • +
    • +

      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.

    + +
    +
    +
    +
    +
    + +
    +
    + + + + + diff --git a/src/flow/pkce-2.html b/src/flow/pkce-2.html index 4c86917..fcb87be 100644 --- a/src/flow/pkce-2.html +++ b/src/flow/pkce-2.html @@ -175,7 +175,7 @@ return window.location.protocol + "//" + window.location.host + "/flow/pkce-3"; } - const baseUrl = "https://sso.rumbuddy.cz/realms/OAuthPlayground/protocol/openid-connect/auth"; + const baseUrl = "https://www.sso.oauth-playground.online/auth"; const responseType = "code"; const clientId = "oauth-playground"; const redirectUri = getRedirectUri(); diff --git a/src/flow/pkce-4.html b/src/flow/pkce-4.html index ecb21ac..252c898 100644 --- a/src/flow/pkce-4.html +++ b/src/flow/pkce-4.html @@ -115,50 +115,40 @@
    Let's break down what we have received...

    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.

    @@ -176,7 +166,7 @@