diff --git a/src/flow/webauthn-2.html b/src/flow/webauthn-2.html new file mode 100644 index 0000000..5fc159c --- /dev/null +++ b/src/flow/webauthn-2.html @@ -0,0 +1,120 @@ + + + + + + OAuth 2.0 Playground - WebAuthn (2/3) + + + + + + + + + + + + + + + +
+
+
+

WebAuthn

+
+
+ 1 +
+
+
+ 2 +
+
+
+ 3 +
+
+
+
+ Build the authorization URL and redirect the user to the authorization server +
+
+ After the user is redirected back to the client, verify that the state matches +
+
+ Exchange the authorization code for an access token +
+
+
+
+
+
+
+
+
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:

+
+

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

    +
  • +
  • +

    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.

    +
  • +
+

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 ()?

+ +
+
+
+
+
+ +
+
+ + + + + + diff --git a/src/flow/webauthn-3.html b/src/flow/webauthn-3.html new file mode 100644 index 0000000..511ca37 --- /dev/null +++ b/src/flow/webauthn-3.html @@ -0,0 +1,221 @@ + + + + + + OAuth 2.0 Playground - WebAuthn (3/3) + + + + + + + + + + + + + + + +
+
+
+

WebAuthn

+
+
+ 1 +
+
+
+ 2 +
+
+
+ 3 +
+
+
+
+ Build the authorization URL and redirect the user to the authorization server +
+
+ After the user is redirected back to the client, verify that the state matches +
+
+ Exchange the authorization code for an access token +
+
+
+
+
+
+
+
+
3. Exchange the code for token
+

Now that we have the authorization code, we can exchange it for an access token. This is done by sending a POST request to the token endpoint.

+
+

With body data:

+
+ Let's break it down...

+
    +
  • +

    +

    The token endpoint URL

    +
  • +
  • +

    grant_type=

    +

    The grant type, in this case 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=

    +

    The redirect URI

    +
  • +
  • +

    code=

    +

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

    +
  • +
+ +
+
+
+
+
+ +
+
+ + + + + + diff --git a/src/flow/webauthn.html b/src/flow/webauthn.html index e307ada..c9d25ef 100644 --- a/src/flow/webauthn.html +++ b/src/flow/webauthn.html @@ -4,7 +4,7 @@ - OAuth 2.0 Playground - Authorization Code Flow + OAuth 2.0 Playground - WebAuthn @@ -174,7 +174,7 @@ } function getRedirectUri() { - return window.location.protocol + "//" + window.location.host + "/flow/code-2"; + return window.location.protocol + "//" + window.location.host + "/flow/webauthn-2"; } const responseType = "code";