mirror of
https://github.com/ysoftdevs/oauth-playground-client.git
synced 2026-01-11 22:41:29 +01:00
Code flow cleanup finished
This commit is contained in:
@@ -203,3 +203,7 @@ pre {
|
||||
margin-top: 25px;
|
||||
padding: 0 10px;
|
||||
}
|
||||
|
||||
.justified {
|
||||
text-align: justify;
|
||||
}
|
||||
|
||||
@@ -1,10 +1,9 @@
|
||||
<!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</title>
|
||||
<title>OAuth 2.0 Playground - Authorization Code Flow (3/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" />
|
||||
@@ -16,13 +15,12 @@
|
||||
<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" style="text-align: center;">Authorization Code Flow</h3>
|
||||
<h3 class="header centered">Authorization Code Flow</h3>
|
||||
<div class="circle-container">
|
||||
<div class="circle">
|
||||
1
|
||||
@@ -36,7 +34,6 @@
|
||||
3
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="row">
|
||||
<div class="col s4 circle-text">
|
||||
Build the authorization URL and redirect the user to the authorization server
|
||||
@@ -57,13 +54,12 @@
|
||||
<h6>3. Exchange the code for token</h6>
|
||||
<p>Now that we have the authorization code, we can exchange it for an access token. This is done by sending a <b>POST</b> request to the token endpoint.</p>
|
||||
<pre class="code-block"><code id="requestUriExample"></code></pre>
|
||||
<p>With body data</p>
|
||||
<p>With body data:</p>
|
||||
<pre class="code-block"><code id="requestBodyExample"></code></pre>
|
||||
<h6>Let's break it down...</h6>
|
||||
<p6>Let's break it down...</p>
|
||||
<ul class="collection">
|
||||
<li class="collection-item">
|
||||
<p><b><span id="tokenUrl"></span></b>
|
||||
</p>
|
||||
<p><b><span id="tokenUrl"></span></b></p>
|
||||
<p>The token endpoint URL</p>
|
||||
</li>
|
||||
<li class="collection-item">
|
||||
@@ -86,19 +82,79 @@
|
||||
access token.</p>
|
||||
</li>
|
||||
</ul>
|
||||
<div class="row" style="text-align: center; margin-top: 25px;">
|
||||
<a style="width: 20%" class="waves-effect waves-light btn"
|
||||
onClick="getToken()">Get token</a>
|
||||
<div class="row flow-submit-container">
|
||||
<a id="get-token-btn" class="waves-effect waves-light btn full-width"
|
||||
onClick="getToken()">Get access token</a>
|
||||
</div>
|
||||
|
||||
<pre class="code-block"><code id="token"></code></pre>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section centered">
|
||||
<a href="/">[ Take me home ]</a>
|
||||
<div id="token-result" style="display: none;" class="section">
|
||||
<div class="col s12 m7">
|
||||
<div class="card horizontal">
|
||||
<div class="card-stacked">
|
||||
<div class="card-content">
|
||||
<h6>Congratulations, you have just obtained an <b>access token</b></h6>
|
||||
<pre class="code-block"><code id="token"></code></pre>
|
||||
<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>
|
||||
</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>
|
||||
</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>
|
||||
</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>
|
||||
</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>
|
||||
</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>
|
||||
<div class="row flow-submit-container">
|
||||
<a class="waves-effect waves-light btn full-width" href="/">Try different flow</a>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</main>
|
||||
@@ -148,7 +204,12 @@
|
||||
})
|
||||
.then(response => response.json())
|
||||
.then(data => {
|
||||
$("#token-result").show();
|
||||
$("#token").text(JSON.stringify(data, null, 2));
|
||||
$("#get-token-btn").hide();
|
||||
$([document.documentElement, document.body]).animate({
|
||||
scrollTop: $("#token-result").offset().top
|
||||
}, 1000);
|
||||
})
|
||||
.catch(error => {
|
||||
console.error('Error fetching the token:', error);
|
||||
|
||||
@@ -48,7 +48,7 @@
|
||||
<div class="card-stacked flow-card">
|
||||
<div class="card-content">
|
||||
<h5>Authorization Code Flow</h5>
|
||||
<p>OAuth 2.0 protocol designed for web applications that can securely store client secrets.
|
||||
<p class="justified">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
|
||||
@@ -66,7 +66,7 @@
|
||||
<div class="card-stacked flow-card">
|
||||
<div class="card-content">
|
||||
<h5>PKCE</h5>
|
||||
<p>Proof Key for Code Exchange is a security protocol for the OAuth 2.0 authorization framework, designed to prevent
|
||||
<p class="justified">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
|
||||
@@ -84,7 +84,7 @@
|
||||
<div class="card-stacked flow-card">
|
||||
<div class="card-content">
|
||||
<h5>Device Authorization Grant</h5>
|
||||
<p>OAuth 2.0 flow optimized for devices that either lack a browser or have limited input
|
||||
<p class="justified">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
|
||||
@@ -103,7 +103,7 @@
|
||||
<div class="card-stacked flow-card">
|
||||
<div class="card-content">
|
||||
<h5>CIBA</h5>
|
||||
<p>Client Initiated Backchannel Authentication is a protocol extension for OAuth 2.0, tailored for scenarios where
|
||||
<p class="justified">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
|
||||
@@ -123,7 +123,7 @@
|
||||
<div class="card-stacked flow-card">
|
||||
<div class="card-content">
|
||||
<h5>WebAuthN</h5>
|
||||
<p>This protocol leverages public key cryptography and allows users to authenticate using biometrics, mobile devices, or
|
||||
<p class="justified">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
|
||||
|
||||
Reference in New Issue
Block a user