From e39fedfeacbf1cfc4f2e2c204d38f3bc392490d9 Mon Sep 17 00:00:00 2001 From: konarfil Date: Thu, 21 Sep 2023 13:36:24 +0200 Subject: [PATCH] First impl of code flow --- src/css/style.css | 25 +++- src/flow/code-1.html | 171 ++++++++++++++++++++++ src/flow/code-2.html | 111 ++++++++++++++ src/flow/code-3.html | 150 +++++++++++++++++++ src/index.html | 82 +++-------- src/layout/footer.html | 36 +++++ src/layout/header.html | 8 + src/pages/authorization-code-flow.html | 93 ------------ src/pages/device-authorization-grant.html | 1 - src/pages/webauthn.html | 1 - 10 files changed, 512 insertions(+), 166 deletions(-) create mode 100644 src/flow/code-1.html create mode 100644 src/flow/code-2.html create mode 100644 src/flow/code-3.html create mode 100644 src/layout/footer.html create mode 100644 src/layout/header.html delete mode 100644 src/pages/authorization-code-flow.html delete mode 100644 src/pages/device-authorization-grant.html delete mode 100644 src/pages/webauthn.html diff --git a/src/css/style.css b/src/css/style.css index 14f4411..fb2a5fe 100644 --- a/src/css/style.css +++ b/src/css/style.css @@ -142,20 +142,33 @@ body { border-radius: 5px; /* rounded corners */ padding: 20px; - /* space inside the block */ - overflow-x: auto; - /* allow horizontal scrolling if code is too wide */ } .code-block code { color: #333; /* dark text color for code */ font-family: "Courier New", Courier, monospace; - /* monospace font */ - white-space: pre; - /* keep whitespace as is */ } .emphasis { color: #FF6600; +} + +pre { + white-space: pre-wrap; + /* CSS3 */ + white-space: -moz-pre-wrap; + /* Firefox */ + white-space: -pre-wrap; + /* Opera <7 */ + white-space: -o-pre-wrap; + /* Opera 7+ */ + word-wrap: break-word; + /* IE */ + overflow-wrap: break-word; + /* CSS3 */ +} + +.card-stacked { + width: 100%; } \ No newline at end of file diff --git a/src/flow/code-1.html b/src/flow/code-1.html new file mode 100644 index 0000000..b562eac --- /dev/null +++ b/src/flow/code-1.html @@ -0,0 +1,171 @@ + + + + + + + OAuth 2.0 Playground + + + + + + + + + + + + +
+
+
+
+

Authorization Code Flow

+
+
+ 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 the state matches +
+
+ Exchange the authorization code for an access token +
+
+
+
+
+
+
+
+
1. Build the Authorization URL
+ + 
?
+            &
+            &
+            &
+            &
+            &
+
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 or Okta). to + find out the proper URL, there always exists + /.well-known/openid-configuration endpoint that contains all the necessary + information. +

    +
    • +
  • +

    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.

    +
    • +
+
+ Send request +
+
+
+
+
+
+
+
+ + + + diff --git a/src/flow/code-2.html b/src/flow/code-2.html new file mode 100644 index 0000000..b80d0a9 --- /dev/null +++ b/src/flow/code-2.html @@ -0,0 +1,111 @@ + + + + + + + OAuth 2.0 Playground + + + + + + + + + + + + +
+
+
+
+

Authorization Code Flow

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

    +

    This is the state parameter that was sent in the initial request. It is used to prevent CSRF attacks.

    +
    • +
  • +

    session_state=

    +

    Session state is a parameter that is used to maintain state between the request and callback. It is used to prevent CSRF attacks.

    +
    • +
  • +

    code=

    +

    This is the authorization code that will be exchanged for an access token.

    +
    • +
+ +

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 +
+
+
+
+
+
+
+
+ + + + diff --git a/src/flow/code-3.html b/src/flow/code-3.html new file mode 100644 index 0000000..3245950 --- /dev/null +++ b/src/flow/code-3.html @@ -0,0 +1,150 @@ + + + + + + + OAuth 2.0 Playground + + + + + + + + + + + + +
+
+
+
+

Authorization Code Flow

+
+
+ 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 the state matches +
+
+ Exchange the authorization code for an access token +
+
+
+
+
+
+
+
+
3. Exchange the code for token
+ +
+
Let's break it down, line by line...
+
    +
  • +

    https://sso.rumbuddy.cz/realms/OAuthPlayground/protocol/openid-connect/token +

    +

    The token endpoint URL

    +
    • +
  • +

    grant_type=authorization_code

    +

    The grant type, in this case authorization_code

    +
    • +
  • +

    client_id=oauth-playground

    +

    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=http://localhost:5555/flow/code-2

    +

    The redirect URI

    +
    • +
  • +

    code=--Vto71vecBQbZnbA7ErehWHVQq4x1pm5YtA9Rr7x5zjhMGS

    +

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

    +
    • +
+
+ Get token +
+ +
+
+
+
+
+
+
+
+ + + + diff --git a/src/index.html b/src/index.html index e741c48..ea9443d 100644 --- a/src/index.html +++ b/src/index.html @@ -12,31 +12,23 @@ + + -
- +
-

Lorem Ipsum

-

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna - aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis - aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint - occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

-

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna - aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. - Duis - aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint - occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

+

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.

@@ -57,7 +49,7 @@ protect the client secret.

- Try it + Try it
@@ -76,7 +68,7 @@ resources without the need for intricate user interactions.

- Try it +
@@ -94,7 +86,7 @@ compromised passwords and defending against phishing attacks.

- Try it +
@@ -103,50 +95,10 @@
-
-
-
-
-
OAuth 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. -

-
-
-
Links
- -
-
-
-
-
- © 2023 Y Soft Corporation - Join us today! -
-
-
- - +
\ No newline at end of file diff --git a/src/layout/footer.html b/src/layout/footer.html new file mode 100644 index 0000000..55ff65b --- /dev/null +++ b/src/layout/footer.html @@ -0,0 +1,36 @@ +
+
+
+
OAuth 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. +

+
+
+
Links
+ +
+
+
+
+
+ © 2023 Y Soft Corporation + Join us today! +
+
diff --git a/src/layout/header.html b/src/layout/header.html new file mode 100644 index 0000000..946d895 --- /dev/null +++ b/src/layout/header.html @@ -0,0 +1,8 @@ + \ No newline at end of file diff --git a/src/pages/authorization-code-flow.html b/src/pages/authorization-code-flow.html deleted file mode 100644 index e718e6e..0000000 --- a/src/pages/authorization-code-flow.html +++ /dev/null @@ -1,93 +0,0 @@ -
-
-

Authorization Code Flow

-
- -
- 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 the state matches -
-
- Exchange the authorization code for an access token -
-
-
-
-
-
-
-
-
1. Build the Authorization URL
- - 
https://sso.rumbuddy.cz/realms/OAuthPlayground/protocol/openid-connect/auth?
-    response_type=code
-    &client_id=oauth-playground
-    &redirect_uri=http://localhost:5555/
-    &scope=offline_access
-    &state=9igSQpeGo2ua52bU
-
-
Let's break it down, line by line...
-
    -
  • -

    https://sso.rumbuddy.cz/realms/OAuthPlayground/protocol/openid-connect/auth?

    -

    URL of the authorization endpoint on the server. How is this path constructed will differ between OAuth providers (such as Keycloak or Okta). to - find out the proper URL, there always exists /.well-known/openid-configuration endpoint that contains all the necessary information. -

    -
    • -
  • -

    response_type=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=oauth-playground

    -

    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=http://localhost:5555/

    -

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

    -
    • -
  • -

    state=9igSQpeGo2ua52bU

    -

    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.

    -
    • -
-
- Send request -
-
-
-
-
-
-
\ No newline at end of file diff --git a/src/pages/device-authorization-grant.html b/src/pages/device-authorization-grant.html deleted file mode 100644 index f47eaf8..0000000 --- a/src/pages/device-authorization-grant.html +++ /dev/null @@ -1 +0,0 @@ -Device Authorization Grant \ No newline at end of file diff --git a/src/pages/webauthn.html b/src/pages/webauthn.html deleted file mode 100644 index b98dee7..0000000 --- a/src/pages/webauthn.html +++ /dev/null @@ -1 +0,0 @@ -WebAuthN \ No newline at end of file