mirror of
https://github.com/ysoftdevs/oauth-playground-client.git
synced 2026-05-05 15:33:32 +02:00
Summary
This commit is contained in:
konarfil
@@ -62,13 +62,6 @@
|
||||
Essentially, it is used to prevent Cross-Site Request Forgery (<a href="https://owasp.org/www-community/attacks/csrf" target="_blank">CSRF</a>) attacks and to ensure the response belongs to the request made by the client.
|
||||
</p>
|
||||
</li>
|
||||
<li class="collection-item">
|
||||
<p><b><span class="emphasis">session_state</span>=<span id="sessionState"></span></b></p>
|
||||
<p>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).</p>
|
||||
</li>
|
||||
<li class="collection-item">
|
||||
<p><b><span class="emphasis">code</span>=<span id="code"></span></b></p>
|
||||
<p>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() {
|
||||
|
||||
@@ -101,50 +101,41 @@
|
||||
<h6>Let's break down what we have received...</h6>
|
||||
<ul class="collection">
|
||||
<li class="collection-item">
|
||||
<p><b>access_token</b></p>
|
||||
<p>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.).
|
||||
It's encoded as a JSON Web Token (JWT), which can be decoded to reveal a header, payload, and signature.
|
||||
The payload of the JWT contains claims about the user and the authentication event. For example, the iss claim indicates
|
||||
the issuer of the token, the aud claim specifies the intended audience for the token, and the exp claim specifies the
|
||||
expiration time of the token. <a href="https://jwt.io/" target="_blank">Want to see what's inside?</a></p>
|
||||
<p><b>token_type</b></p>
|
||||
<p>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.</p>
|
||||
</li>
|
||||
<li class="collection-item">
|
||||
<p><b>expires_in</b></p>
|
||||
<p>Indicates the number of seconds for which the <b>access_token</b> is valid. After this time, the access_token will expire and a
|
||||
new one must be obtained.</p>
|
||||
<p>Indicates the number of seconds for which the <b>access_token</b> is valid. After this time, the access_token
|
||||
will expire and a
|
||||
new one must be obtained.</p>
|
||||
</li>
|
||||
<li class="collection-item">
|
||||
<p><b>refresh_expires_in</b></p>
|
||||
<p>Indicates the number of seconds for which the refresh_token is valid. Once the refresh token is expired, the client will
|
||||
need to re-authenticate the user to get a new set of tokens.</p>
|
||||
<p><b>access_token</b></p>
|
||||
<p>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.).
|
||||
</p>
|
||||
</li>
|
||||
<li class="collection-item">
|
||||
<p><b>refresh_token</b></p>
|
||||
<p>Used to obtain a new <b>access_token</b> when the current one expires. This allows the client to get a new <b>access_token</b> without
|
||||
requiring the user to log in again. Like the <b>access_token</b>, it's encoded as a JWT.</p>
|
||||
</li>
|
||||
<li class="collection-item">
|
||||
<p><b>token_type</b></p>
|
||||
<p>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.</p>
|
||||
</li>
|
||||
<li class="collection-item">
|
||||
<p><b>not-before-policy</b></p>
|
||||
<p>Specifies a time before which the token should not be accepted. A value of 0 implies the token can be immediately used.</p>
|
||||
</li>
|
||||
<li class="collection-item">
|
||||
<p><b>session_state</b></p>
|
||||
<p>Represents the state of the user's session at the Authorization Server. This is the same value that could was
|
||||
returned during the Authorization Code Flow in the <b>session_state</b> parameter.
|
||||
It can be used in scenarios like OpenID Connect session management to monitor the user's session.</p>
|
||||
<p>Used to obtain a new <b>access_token</b> when the current one expires. This allows the client to get a new
|
||||
<b>access_token</b> without
|
||||
requiring the user to log in again.
|
||||
</p>
|
||||
</li>
|
||||
<li class="collection-item">
|
||||
<p><b>scope</b></p>
|
||||
<p>Specifies the scopes granted by the user to the client application. Scopes determine the permissions associated with the
|
||||
<b>access_token</b>. 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).</p>
|
||||
<p>Specifies the scopes granted by the user to the client application. Scopes determine the permissions
|
||||
associated with the
|
||||
<b>access_token</b>. 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).
|
||||
</p>
|
||||
</li>
|
||||
</ul>
|
||||
<p>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.</p>
|
||||
@@ -161,7 +152,7 @@
|
||||
<footer class="page-footer"></footer>
|
||||
<script src="../js/load-layout.js"></script>
|
||||
<script>
|
||||
const tokenEndpoint = 'https://sso.rumbuddy.cz/realms/OAuthPlayground/protocol/openid-connect/token';
|
||||
const tokenEndpoint = 'https://www.sso.oauth-playground.online/auth/token';
|
||||
const clientID = 'oauth-playground';
|
||||
const code = new URLSearchParams(window.location.search).get('code');
|
||||
|
||||
|
||||
@@ -153,7 +153,7 @@
|
||||
return window.location.protocol + "//" + window.location.host + "/flow/code-2";
|
||||
}
|
||||
|
||||
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();
|
||||
169
src/flow/dag.html
Normal file
169
src/flow/dag.html
Normal file
@@ -0,0 +1,169 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<title>OAuth 2.0 Playground - Device Authorization Grant (1/3)</title>
|
||||
<link rel="icon" href="../favicon.ico" type="image/x-icon">
|
||||
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/materialize/1.0.0/css/materialize.min.css">
|
||||
<link type="text/css" rel="stylesheet" href="../css/style.css" />
|
||||
<link rel="preconnect" href="https://fonts.googleapis.com" />
|
||||
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />
|
||||
<link rel="stylesheet"
|
||||
href="https://fonts.googleapis.com/css2?family=Roboto:wght@300;400;500;600;700&display=swap" />
|
||||
<link rel="stylesheet" href="https://fonts.googleapis.com/icon?family=Material+Icons" />
|
||||
<script src="https://code.jquery.com/jquery-3.6.0.min.js"></script>
|
||||
<script src="https://cdnjs.cloudflare.com/ajax/libs/materialize/1.0.0/js/materialize.min.js"></script>
|
||||
</head>
|
||||
<body>
|
||||
<header id="page-header"></header>
|
||||
<main>
|
||||
<div class="container">
|
||||
<div class="section">
|
||||
<h3 class="header centered">Device Authorization Grant</h3>
|
||||
<div class="circle-container circle-3">
|
||||
<div class="circle">
|
||||
1
|
||||
</div>
|
||||
<div class="line line-inactive"></div>
|
||||
<div class="circle circle-inactive">
|
||||
2
|
||||
</div>
|
||||
<div class="line line-inactive"></div>
|
||||
<div class="circle circle-inactive">
|
||||
3
|
||||
</div>
|
||||
</div>
|
||||
<div class="row">
|
||||
<div class="col s4 circle-text">
|
||||
Request a device code from the authorization server
|
||||
</div>
|
||||
<div class="col s4 circle-text">
|
||||
Instruct the user where to enter the code
|
||||
</div>
|
||||
<div class="col s4 circle-text">
|
||||
Poll the authorization server periodically until the code has been successfully entered
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section">
|
||||
<div class="col s12 m7">
|
||||
<div class="card horizontal">
|
||||
<div class="card-stacked">
|
||||
<div class="card-content">
|
||||
<h6>1. Request a Device Code</h6>
|
||||
<p>
|
||||
In order to initiate the <b>Device Authorization Grant</b>, we need to request a device code from the authorization server. The request is sent to the following URL:
|
||||
</p>
|
||||
<pre class="code-block"><code id="requestUriExample"></code></pre>
|
||||
<p>With body data:</p>
|
||||
<pre class="code-block"><code id="requestBodyExample"></code></pre>
|
||||
<p>Let's break it down...</p>
|
||||
<ul class="collection">
|
||||
<li class="collection-item">
|
||||
<p><b><span id="baseUrl"></span></b>
|
||||
</p>
|
||||
<p>URL of the authorization endpoint on the server. How is this path constructed will
|
||||
differ between OAuth providers (such as Keycloak, Okta, etc.).
|
||||
</p>
|
||||
</li>
|
||||
<li class="collection-item">
|
||||
<p><b><span class="emphasis">response_type</span>=<span id="responseType"></span></b></p>
|
||||
<p>OAuth 2.0 response type. In this case, we are using the Authorization Code flow, so
|
||||
we are requesting the authorization <b>code</b>.</p>
|
||||
</li>
|
||||
<li class="collection-item">
|
||||
<p><b><span class="emphasis">client_id</span>=<span id="clientId"></span></b></p>
|
||||
<p>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.</p>
|
||||
</li>
|
||||
<li class="collection-item">
|
||||
<p><b><span class="emphasis">redirect_uri</span>=<span id="redirectUri"></span></b></p>
|
||||
<p>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.</p>
|
||||
</li>
|
||||
<li class="collection-item">
|
||||
<p><b><span class="emphasis">scope</span>=<span id="scope"></span></b></p>
|
||||
<p>Scopes requested by the client. Scopes are used to limit the access of the access
|
||||
token. In this case, we are requesting the <b>offline_access</b> scope,
|
||||
which allows the client to obtain a refresh token.</p>
|
||||
</li>
|
||||
<li class="collection-item">
|
||||
<p><b><span class="emphasis">state</span>=<span id="state"></span></b></p>
|
||||
<p>State parameter. This is an <b>optional parameter</b> 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 (<a href="https://owasp.org/www-community/attacks/csrf" target="_blank">CSRF attack</a>).</p>
|
||||
</li>
|
||||
</ul>
|
||||
<p>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 <b>user</b> with password <b>user</b> for you. After your credentials are successfully verified, you will be redirected back to this playground, to the URL we have specified in the <b>redirect_uri</b> query parameter of the request.</p>
|
||||
<div class="row flow-submit-container">
|
||||
<a id="sendRequestBtn" class="waves-effect waves-light btn full-width"
|
||||
href="#">Authenticate</a>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section centered">
|
||||
<a href="/">[ Take me home ]</a>
|
||||
</div>
|
||||
</div>
|
||||
</main>
|
||||
<footer class="page-footer"></footer>
|
||||
<script src="../js/load-layout.js"></script>
|
||||
<script>
|
||||
function generateSessionState () {
|
||||
return Math.random().toString(36).substring(2, 15) + Math.random().toString(36).substring(2, 15);
|
||||
}
|
||||
|
||||
function constructRequestUrl () {
|
||||
return baseUrl
|
||||
+ "?" + "response_type=" + responseType
|
||||
+ "&" + "client_id=" + clientId
|
||||
+ "&" + "redirect_uri=" + redirectUri
|
||||
+ "&" + "scope=" + scope
|
||||
+ "&" + "state=" + state;
|
||||
}
|
||||
|
||||
function fillExample() {
|
||||
const requestExample = baseUrl + "\n"
|
||||
+ " ?response_type=" + responseType + "\n"
|
||||
+ " &client_id=" + clientId + "\n"
|
||||
+ " &redirect_uri=" + redirectUri + "\n"
|
||||
+ " &scope=" + scope + "\n"
|
||||
+ " &state=" + state;
|
||||
|
||||
$("#requestUriExample").text(baseUrl);
|
||||
$("#requestBodyExample").text("client_id=" + clientId);
|
||||
$("#baseUrl").text(baseUrl);
|
||||
$("#responseType").text(responseType);
|
||||
$("#clientId").text(clientId);
|
||||
$("#redirectUri").text(redirectUri);
|
||||
$("#scope").text(scope);
|
||||
$("#state").text(state);
|
||||
}
|
||||
|
||||
function getRedirectUri() {
|
||||
return window.location.protocol + "//" + window.location.host + "/flow/code-2";
|
||||
}
|
||||
|
||||
const baseUrl = "https://sso.rumbuddy.cz/realms/OAuthPlayground/protocol/openid-connect/device";
|
||||
const responseType = "code";
|
||||
const clientId = "oauth-playground";
|
||||
const redirectUri = getRedirectUri();
|
||||
const scope = "offline_access";
|
||||
const state = generateSessionState();
|
||||
|
||||
fillExample();
|
||||
$("#sendRequestBtn").attr("href", constructRequestUrl());
|
||||
</script>
|
||||
</body>
|
||||
</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();
|
||||
|
||||
@@ -115,50 +115,40 @@
|
||||
<h6>Let's break down what we have received...</h6>
|
||||
<ul class="collection">
|
||||
<li class="collection-item">
|
||||
<p><b>access_token</b></p>
|
||||
<p>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.).
|
||||
It's encoded as a JSON Web Token (JWT), which can be decoded to reveal a header, payload, and signature.
|
||||
The payload of the JWT contains claims about the user and the authentication event. For example, the iss claim indicates
|
||||
the issuer of the token, the aud claim specifies the intended audience for the token, and the exp claim specifies the
|
||||
expiration time of the token. <a href="https://jwt.io/" target="_blank">Want to see what's inside?</a></p>
|
||||
<p><b>token_type</b></p>
|
||||
<p>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.</p>
|
||||
</li>
|
||||
<li class="collection-item">
|
||||
<p><b>expires_in</b></p>
|
||||
<p>Indicates the number of seconds for which the <b>access_token</b> is valid. After this time, the access_token will expire and a
|
||||
new one must be obtained.</p>
|
||||
<p>Indicates the number of seconds for which the <b>access_token</b> is valid. After this time, the access_token
|
||||
will expire and a
|
||||
new one must be obtained.</p>
|
||||
</li>
|
||||
<li class="collection-item">
|
||||
<p><b>refresh_expires_in</b></p>
|
||||
<p>Indicates the number of seconds for which the refresh_token is valid. Once the refresh token is expired, the client will
|
||||
need to re-authenticate the user to get a new set of tokens.</p>
|
||||
<p><b>access_token</b></p>
|
||||
<p>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.).
|
||||
</p>
|
||||
</li>
|
||||
<li class="collection-item">
|
||||
<p><b>refresh_token</b></p>
|
||||
<p>Used to obtain a new <b>access_token</b> when the current one expires. This allows the client to get a new <b>access_token</b> without
|
||||
requiring the user to log in again. Like the <b>access_token</b>, it's encoded as a JWT.</p>
|
||||
</li>
|
||||
<li class="collection-item">
|
||||
<p><b>token_type</b></p>
|
||||
<p>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.</p>
|
||||
</li>
|
||||
<li class="collection-item">
|
||||
<p><b>not-before-policy</b></p>
|
||||
<p>Specifies a time before which the token should not be accepted. A value of 0 implies the token can be immediately used.</p>
|
||||
</li>
|
||||
<li class="collection-item">
|
||||
<p><b>session_state</b></p>
|
||||
<p>Represents the state of the user's session at the Authorization Server. This is the same value that could was
|
||||
returned during the Authorization Code Flow in the <b>session_state</b> parameter.
|
||||
It can be used in scenarios like OpenID Connect session management to monitor the user's session.</p>
|
||||
<p>Used to obtain a new <b>access_token</b> when the current one expires. This allows the client to get a new
|
||||
<b>access_token</b> without
|
||||
requiring the user to log in again.</p>
|
||||
</li>
|
||||
<li class="collection-item">
|
||||
<p><b>scope</b></p>
|
||||
<p>Specifies the scopes granted by the user to the client application. Scopes determine the permissions associated with the
|
||||
<b>access_token</b>. 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).</p>
|
||||
<p>Specifies the scopes granted by the user to the client application. Scopes determine the permissions
|
||||
associated with the
|
||||
<b>access_token</b>. 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).
|
||||
</p>
|
||||
</li>
|
||||
</ul>
|
||||
<p>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.</p>
|
||||
@@ -176,7 +166,7 @@
|
||||
<script src="../js/load-layout.js"></script>
|
||||
<script src="../js/cookies.js"></script>
|
||||
<script>
|
||||
const tokenEndpoint = 'https://sso.rumbuddy.cz/realms/OAuthPlayground/protocol/openid-connect/token';
|
||||
const tokenEndpoint = 'https://www.sso.oauth-playground.online/auth/token';
|
||||
const clientID = 'oauth-playground';
|
||||
const code = new URLSearchParams(window.location.search).get('code');
|
||||
const codeVerifier = getCookie("code_verifier");
|
||||
|
||||
Reference in New Issue
Block a user