lsm/openiddict-documentation
1
0
Fork 0
mirror of https://gitee.com/dcren/openiddict-documentation.git synced 2025-09-23 20:43:33 +08:00
Code Issues Actions Packages Projects Releases Wiki Activity

Update the documentation pages

Browse Source
This commit is contained in:
OpenIddict Bot
2021-05-19 15:30:14 +00:00
parent 4fea08a178
commit 958468917f
10 changed files with 493 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

153
configuration/proof-key-for-code-exchange.html Normal file
View File

@@ -0,0 +1,153 @@
<!DOCTYPE html>
<!--[if IE]><![endif]-->
<html>
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
<title>Proof Key for Code Exchange </title>
<meta name="viewport" content="width=device-width">
<meta name="title" content="Proof Key for Code Exchange ">
<meta name="generator" content="docfx 2.56.7.0">
<link rel="shortcut icon" href="../images/favicon.ico">
<link rel="stylesheet" href="../styles/docfx.vendor.css">
<link rel="stylesheet" href="../styles/docfx.css">
<link rel="stylesheet" href="../styles/main.css">
<link href="https://fonts.googleapis.com/css?family=Roboto" rel="stylesheet">
<meta property="docfx:navrel" content="../toc.html">
<meta property="docfx:tocrel" content="toc.html">
</head> <body data-spy="scroll" data-target="#affix" data-offset="120">
<div id="wrapper">
<header>
<nav id="autocollapse" class="navbar navbar-inverse ng-scope" role="navigation">
<div class="container">
<div class="navbar-header">
<button type="button" class="navbar-toggle" data-toggle="collapse" data-target="#navbar">
<span class="sr-only">Toggle navigation</span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
</button>
<a class="navbar-brand" href="../index.html">
<img id="logo" class="svg" src="../images/logo.png" alt="">
</a> </div>
<div class="collapse navbar-collapse" id="navbar">
<form class="navbar-form navbar-right" role="search" id="search">
<div class="form-group">
<input type="text" class="form-control" id="search-query" placeholder="Search" autocomplete="off">
</div>
</form>
</div>
</div>
</nav>
<div class="subnav navbar navbar-default">
<div class="container hide-when-search" id="breadcrumb">
<ul class="breadcrumb">
<li></li>
</ul>
</div>
</div>
</header>
<div role="main" class="container body-content hide-when-search">
<div class="sidenav hide-when-search">
<a class="btn toc-toggle collapse" data-toggle="collapse" href="#sidetoggle" aria-expanded="false" aria-controls="sidetoggle">Show / Hide Table of Contents</a>
<div class="sidetoggle collapse" id="sidetoggle">
<div id="sidetoc"></div>
</div>
</div>
<div class="article row grid-right">
<div class="col-md-10">
<article class="content wrap" id="_content" data-uid="">
<h1 id="proof-key-for-code-exchange">Proof Key for Code Exchange</h1>
<p>Initially designed as a way to protect mobile applications from seeing their callback URIs hijacked by a malicious application installed on the same device,
the <a href="https://tools.ietf.org/html/rfc7636">Proof Key for Code Exchange (PKCE)</a> mechanism has been extended to confidential clients to help mitigate authorization code leakages.
This mechanism is fully supported by all versions of OpenIddict and can be enforced globally or per-client to block authorization requests that don&#39;t send PKCE parameters.</p>
<h2 id="enabling-pkce-enforcement-at-the-global-level">Enabling PKCE enforcement at the global level</h2>
<p>Proof Key for Code Exchange can be enforced globally by calling <code>options.RequireProofKeyForCodeExchange()</code> in the server options:</p>
<pre><code class="lang-csharp">services.AddOpenIddict()
.AddServer(options =&gt;
{
options.RequireProofKeyForCodeExchange();
});
</code></pre><h2 id="enabling-pkce-enforcement-per-client">Enabling PKCE enforcement per client</h2>
<p>Proof Key for Code Exchange can also be enforced per-client by adding it to the list of requirements attached to a client:</p>
<pre><code class="lang-csharp">await manager.CreateAsync(new OpenIddictApplicationDescriptor
{
ClientId = &quot;mvc&quot;,
ClientSecret = &quot;901564A5-E7FE-42CB-B10D-61EF6A8F3654&quot;,
ConsentType = ConsentTypes.Explicit,
PostLogoutRedirectUris =
{
new Uri(&quot;https://localhost:44381/signout-callback-oidc&quot;)
},
RedirectUris =
{
new Uri(&quot;https://localhost:44381/signin-oidc&quot;)
},
Permissions =
{
Permissions.Endpoints.Authorization,
Permissions.Endpoints.Logout,
Permissions.Endpoints.Token,
Permissions.GrantTypes.AuthorizationCode,
Permissions.GrantTypes.RefreshToken,
Permissions.ResponseTypes.Code,
Permissions.Scopes.Email,
Permissions.Scopes.Profile,
Permissions.Scopes.Roles,
Permissions.Prefixes.Scope + &quot;demo_api&quot;
},
Requirements =
{
Requirements.Features.ProofKeyForCodeExchange
}
});
</code></pre></article>
</div>
<div class="hidden-sm col-md-2" role="complementary">
<div class="sideaffix">
<div class="contribution">
<ul class="nav">
<li>
<a href="https://github.com/openiddict/openiddict-documentation/blob/dev/configuration/proof-key-for-code-exchange.md/#L1" class="contribution-link">Improve this Doc</a>
</li>
</ul>
</div>
<nav class="bs-docs-sidebar hidden-print hidden-xs hidden-sm affix" id="affix">
<h5>In This Article</h5>
<div></div>
</nav>
</div>
</div>
</div>
</div>
<footer>
<div class="grad-bottom"></div>
<div class="footer">
<div class="container">
<span class="pull-right">
<a href="#top">Back to top</a>
</span>
<span>Generated by <strong>DocFX</strong></span>
</div>
</div>
</footer>
</div>
<script type="text/javascript" src="../styles/docfx.vendor.js"></script>
<script type="text/javascript" src="../styles/docfx.js"></script>
<script type="text/javascript" src="../styles/main.js"></script>
</body>
</html>

3
configuration/toc.html
View File

@@ -24,6 +24,9 @@
<li>
<a href="claim-destinations.html" name="" title="Claim destinations">Claim destinations</a>
</li>
<li>
<a href="proof-key-for-code-exchange.html" name="" title="Proof Key for Code Exchange">Proof Key for Code Exchange</a>
</li>
<li>
<a href="token-formats.html" name="" title="Token formats">Token formats</a>
</li>

252
guide/choosing-the-right-flow.html Normal file
View File

@@ -0,0 +1,252 @@
<!DOCTYPE html>
<!--[if IE]><![endif]-->
<html>
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
<title>Non-interactive flows </title>
<meta name="viewport" content="width=device-width">
<meta name="title" content="Non-interactive flows ">
<meta name="generator" content="docfx 2.56.7.0">
<link rel="shortcut icon" href="../images/favicon.ico">
<link rel="stylesheet" href="../styles/docfx.vendor.css">
<link rel="stylesheet" href="../styles/docfx.css">
<link rel="stylesheet" href="../styles/main.css">
<link href="https://fonts.googleapis.com/css?family=Roboto" rel="stylesheet">
<meta property="docfx:navrel" content="../toc.html">
<meta property="docfx:tocrel" content="toc.html">
</head> <body data-spy="scroll" data-target="#affix" data-offset="120">
<div id="wrapper">
<header>
<nav id="autocollapse" class="navbar navbar-inverse ng-scope" role="navigation">
<div class="container">
<div class="navbar-header">
<button type="button" class="navbar-toggle" data-toggle="collapse" data-target="#navbar">
<span class="sr-only">Toggle navigation</span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
</button>
<a class="navbar-brand" href="../index.html">
<img id="logo" class="svg" src="../images/logo.png" alt="">
</a> </div>
<div class="collapse navbar-collapse" id="navbar">
<form class="navbar-form navbar-right" role="search" id="search">
<div class="form-group">
<input type="text" class="form-control" id="search-query" placeholder="Search" autocomplete="off">
</div>
</form>
</div>
</div>
</nav>
<div class="subnav navbar navbar-default">
<div class="container hide-when-search" id="breadcrumb">
<ul class="breadcrumb">
<li></li>
</ul>
</div>
</div>
</header>
<div role="main" class="container body-content hide-when-search">
<div class="sidenav hide-when-search">
<a class="btn toc-toggle collapse" data-toggle="collapse" href="#sidetoggle" aria-expanded="false" aria-controls="sidetoggle">Show / Hide Table of Contents</a>
<div class="sidetoggle collapse" id="sidetoggle">
<div id="sidetoc"></div>
</div>
</div>
<div class="article row grid-right">
<div class="col-md-10">
<article class="content wrap" id="_content" data-uid="">
<p>OpenIddict offers built-in support for all the standard flows defined by the
<a href="https://tools.ietf.org/html/rfc6749">OAuth 2.0</a> and <a href="https://openid.net/specs/openid-connect-core-1_0.html">OpenID Connect</a> core specifications:
<a href="https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth">the authorization code flow</a>,
<a href="https://openid.net/specs/openid-connect-core-1_0.html#ImplicitFlowAuth">the implicit flow</a>,
<a href="https://openid.net/specs/openid-connect-core-1_0.html#HybridFlowAuth">the hybrid flow</a> (which is basically a mix between the first two flows),
<a href="https://tools.ietf.org/html/rfc6749#section-4.3">the resource owner password credentials grant</a> and
<a href="https://tools.ietf.org/html/rfc6749#section-4.4">the client credentials grant</a>.</p>
<p>While not specific to OpenIddict, choosing the best flow(s) for your application is an <strong>important prerequisite</strong>
when implementing your own authorization server ; so here&#39;s a quick overview of the different OAuth 2.0/OpenID Connect flows:</p>
<hr>
<h2 id="non-interactive-flows">Non-interactive flows</h2>
<h3 id="resource-owner-password-credentials-flow-not-recommended-for-new-applications">Resource owner password credentials flow (not recommended for new applications)</h3>
<p>Directly inspired by <a href="https://en.wikipedia.org/wiki/Basic_access_authentication">basic authentication</a>, the resource owner password credentials grant
(abbreviated <em>ROPC</em>) is conceptually <strong>the simplest OAuth 2.0 flow</strong>: the client application asks the user his username/password, sends a token request
to the authorization server with the user credentials (and depending on the client authentication policy defined by the authorization server,
its own client credentials) and gets back an access token it can use to retrieve the user&#39;s resources.</p>
<p><img src="choosing-the-right-flow/resource-owner-password-flow.png" alt="Resource owner password credentials flow"></p>
<pre><code class="lang-http">POST /connect/token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=password&amp;username=johndoe&amp;password=A3ddj3w
</code></pre><pre><code class="lang-http">HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
&quot;access_token&quot;:&quot;2YotnFZFEjr1zCsicMWpAA&quot;,
&quot;token_type&quot;:&quot;bearer&quot;,
&quot;expires_in&quot;:3600
}
</code></pre><div class="CAUTION"><h5>Caution</h5><p>This flow is <strong>not recommended by the OAuth 2.0 specification</strong> as it&#39;s the only grant type where <strong>the user password is directly exposed to the client application</strong>,
which breaks the principle of least privilege and <strong>makes it unsuitable for third-party client applications that can&#39;t be fully trusted by the authorization server</strong>.</p>
<p>While popular and trivial to implement (as it doesn&#39;t involve any redirection or consent form and unlike interactive flows, doesn&#39;t require implementing
cross-site request forgery (XSRF) countermeasures to prevent session fixation attacks), <strong>its use in new applications is not recommended</strong>. Instead,
users are encouraged to use the authorization code flow, that doesn&#39;t expose passwords to client applications and is not limited to password authentication.</p>
</div>
<!-- more -->
<hr>
<h3 id="client-credentials-grant-recommended-for-machine-to-machine-communication">Client credentials grant (recommended for machine-to-machine communication)</h3>
<p>The client credentials grant is almost identical to the resource owner password credentials grant, except it&#39;s been specifically designed for <strong>client-to-server scenarios</strong>
(no user is involved in this flow): the client application sends a token request containing its credentials and gets back an access token it can use to query its own resources.</p>
<p><img src="choosing-the-right-flow/client-credentials-flow.png" alt="Client credentials flow"></p>
<pre><code class="lang-http">POST /connect/token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials&amp;client_id=s6BhdRkqt3&amp;client_secret=gX1fBat3bV
</code></pre><pre><code class="lang-http">HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
&quot;access_token&quot;:&quot;2YotnFZFEjr1zCsicMWpAA&quot;,
&quot;token_type&quot;:&quot;bearer&quot;,
&quot;expires_in&quot;:3600
}
</code></pre><div class="NOTE"><h5>Note</h5><p>Unlike the resource owner password credentials grant, <strong>client authentication is not optional</strong> when using the client credentials grant and
<strong>OpenIddict will always reject unauthenticated token requests</strong>, <a href="https://tools.ietf.org/html/rfc6749#section-4.4.2">as required by the OAuth 2.0 specification</a>.</p>
<p>This means that <strong>you CAN&#39;T use the client credentials grant with public applications</strong> like browser,
mobile or desktop applications, as they are not able to keep their credentials secret.</p>
</div>
<hr>
<h2 id="interactive-flows">Interactive flows</h2>
<h3 id="authorization-code-flow-recommended-for-new-applications">Authorization code flow (recommended for new applications)</h3>
<p>While the authorization code flow is probably the most complicated flow (as it involves both <strong>user-agent redirections and backchannel communication</strong>), it&#39;s
<strong>the recommended flow for any scenario involving end users, whether they log in using a password, a PIN, a smart card or even an external provider</strong>.
In return for its complexity, this flow has a great advantage when used in server-side applications: the <code>access_token</code> cannot be intercepted by the user agent.</p>
<p>There are basically 2 steps in the authorization code flow: the authorization request/response and the token request/response.</p>
<p><img src="choosing-the-right-flow/authorization-code-flow.png" alt="Authorization code flow"></p>
<ul>
<li><strong>Step 1: the authorization request</strong></li>
</ul>
<p>In this flow, the client application always initiates the authentication process by generating an authorization request including
the mandatory <code>response_type=code</code> parameter, its <code>client_id</code>, its <code>redirect_uri</code> and optionally, a <code>scope</code> and a <code>state</code> parameter
<a href="https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest">that allows flowing custom data and helps mitigate XSRF attacks</a>.</p>
<div class="NOTE"><h5>Note</h5><p>In most cases, the client application will simply return a 302 response with a <code>Location</code> header to redirect the user agent to the authorization endpoint,
but depending on the OpenID Connect client you&#39;re using, POST requests might also be supported to allow you to send large authorization requests.
This feature <a href="https://github.com/aspnet/Security/pull/392">is usually implemented using an auto-post HTML form</a>.</p>
</div>
<pre><code class="lang-http">HTTP/1.1 302 Found
Location: https://server.example.com/authorize?response_type=code&amp;client_id=s6BhdRkqt3&amp;state=af0ifjsldkj&amp;redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
</code></pre><pre><code class="lang-http">GET /connect/authorize?response_type=code&amp;client_id=s6BhdRkqt3&amp;state=af0ifjsldkj&amp;redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1
Host: server.example.com
</code></pre><p>The way the identity provider handles the authorization request is implementation-specific but in most cases, a consent form
is displayed to ask the user if he or she agrees to share his/her personal data with the client application.</p>
<p><img src="choosing-the-right-flow/consent-form.png" alt="Consent form"></p>
<p>When the consent is given, the user agent is redirected back to the client application with <strong>a unique and short-lived token</strong>
named <em>authorization code</em> that the client will be able to exchange with an access token by sending a token request.</p>
<pre><code class="lang-http">HTTP/1.1 302 Found
Location: https://client.example.org/cb?code=SplxlOBeZQQYbYS6WxSbIA&amp;state=af0ifjsldkj
</code></pre><div class="WARNING"><h5>Warning</h5><p>To prevent XSRF/session fixation attacks, <strong>the client application MUST ensure that the <code>state</code> parameter returned by the identity provider
corresponds to the original <code>state</code></strong> and stop processing the authorization response if the two values don&#39;t match.
<a href="https://tools.ietf.org/html/rfc6749#section-10.12">This is usually done by generating a non-guessable string and a corresponding correlation cookie</a>.</p>
</div>
<ul>
<li><strong>Step 2: the token request</strong></li>
</ul>
<p>When the client application gets back an authorization code, it must immediately reedem it for an access token by sending a <code>grant_type=authorization_code</code> token request.</p>
<div class="NOTE"><h5>Note</h5><p>To help the identity provider <a href="https://tools.ietf.org/html/rfc6819#section-4.4.1.7">mitigate counterfeit clients attacks</a>, the original <code>redirect_uri</code> must also be sent.</p>
<p>If the client application is a confidential application (i.e an application that has been assigned client credentials), authentication is required.</p>
</div>
<pre><code class="lang-http">POST /connect/token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&amp;code=SplxlOBeZQQYbYS6WxSbIA&amp;redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb&amp;client_id=s6BhdRkqt3&amp;client_secret=gX1fBat3bV&amp;scope=openid
</code></pre><pre><code class="lang-http">HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
&quot;access_token&quot;:&quot;2YotnFZFEjr1zCsicMWpAA&quot;,
&quot;token_type&quot;:&quot;bearer&quot;,
&quot;expires_in&quot;:3600
}
</code></pre><div class="NOTE"><h5>Note</h5><p>To increase security, additional parameters such as <code>code_challenge</code> and <code>code_challenge_method</code> can be specified to bind the authorization code
that will be returned by the authorization endpoint to the original authorization request. This mechanism is known as
<a href="../configuration/proof-key-for-code-exchange.html">Proof Key for Code Exchange</a> and is fully supported by OpenIddict. </p>
</div>
<hr>
<h3 id="implicit-flow-not-recommended-for-new-applications">Implicit flow (not recommended for new applications)</h3>
<p>The implicit flow is similar to the authorization code flow, <strong>except there&#39;s no token request/response step</strong>: the access token is directly returned
to the client application as part of the authorization response in the URI fragment (or in the request form when using <code>response_mode=form_post</code>).</p>
<p><img src="choosing-the-right-flow/implicit-flow.png" alt="Implicit flow"></p>
<pre><code class="lang-http">GET /connect/authorize?response_type=token&amp;client_id=s6BhdRkqt3&amp;redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb&amp;scope=openid&amp;state=af0ifjsldkj&amp;nonce=n-0S6_WzA2Mj HTTP/1.1
Host: server.example.com
</code></pre><pre><code class="lang-http">HTTP/1.1 302 Found
Location: https://client.example.org/cb#access_token=SlAV32hkKG&amp;token_type=bearer&amp;expires_in=3600&amp;state=af0ifjsldkj
</code></pre><div class="CAUTION"><h5>Caution</h5><p>Initially designed for browser applications, this flow is inherently less secure than the authorization code flow and doesn&#39;t support
<a href="https://tools.ietf.org/html/rfc7636">Proof Key for Code Exchange</a>. As such, using it in new applications is not recommended.</p>
</div>
<div class="WARNING"><h5>Warning</h5><p>To prevent XSRF/session fixation attacks, <strong>the client application MUST ensure that the <code>state</code> parameter returned by the identity provider
corresponds to the original <code>state</code></strong> and stop processing the authorization response if the two values don&#39;t match.
<a href="https://tools.ietf.org/html/rfc6749#section-10.12">This is usually done by generating a non-guessable string and a corresponding value stored in the local storage</a>.</p>
<p>When using the implicit flow, <strong>the client application MUST also ensure that the access token was not issued
to another application to prevent <a href="https://stackoverflow.com/a/17439317/542757">confused deputy attacks</a>.</strong>
With OpenID Connect, this can be done by using <code>response_type=id_token token</code> and checking the <code>aud</code> claim
of the JWT identity token, that must correspond or contain the <code>client_id</code> of the client application.</p>
</div>
</article>
</div>
<div class="hidden-sm col-md-2" role="complementary">
<div class="sideaffix">
<div class="contribution">
<ul class="nav">
<li>
<a href="https://github.com/openiddict/openiddict-documentation/blob/dev/guide/choosing-the-right-flow.md/#L1" class="contribution-link">Improve this Doc</a>
</li>
</ul>
</div>
<nav class="bs-docs-sidebar hidden-print hidden-xs hidden-sm affix" id="affix">
<h5>In This Article</h5>
<div></div>
</nav>
</div>
</div>
</div>
</div>
<footer>
<div class="grad-bottom"></div>
<div class="footer">
<div class="container">
<span class="pull-right">
<a href="#top">Back to top</a>
</span>
<span>Generated by <strong>DocFX</strong></span>
</div>
</div>
</footer>
</div>
<script type="text/javascript" src="../styles/docfx.vendor.js"></script>
<script type="text/javascript" src="../styles/docfx.js"></script>
<script type="text/javascript" src="../styles/main.js"></script>
</body>
</html>

BIN
guide/choosing-the-right-flow/authorization-code-flow.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 20 KiB

BIN
guide/choosing-the-right-flow/client-credentials-flow.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 5.7 KiB

BIN
guide/choosing-the-right-flow/consent-form.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 23 KiB

BIN
guide/choosing-the-right-flow/implicit-flow.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 21 KiB

BIN
guide/choosing-the-right-flow/resource-owner-password-flow.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 12 KiB

3
guide/toc.html
View File

@@ -18,6 +18,9 @@
<li>
<a href="getting-started.html" name="" title="Getting started">Getting started</a>
</li>
<li>
<a href="choosing-the-right-flow.html" name="" title="Choosing the right flow">Choosing the right flow</a>
</li>
<li>
<span class="expand-stub"></span>
<a>Migration guides</a>

85
manifest.json
View File

@@ -5643,13 +5643,25 @@
"is_incremental": false,
"version": ""
},
{
"type": "Conceptual",
"source_relative_path": "configuration/proof-key-for-code-exchange.md",
"output": {
".html": {
"relative_path": "configuration/proof-key-for-code-exchange.html",
"hash": "ijKd83k3Oi01O5QoJk8jvA=="
}
},
"is_incremental": false,
"version": ""
},
{
"type": "Toc",
"source_relative_path": "configuration/toc.yml",
"output": {
".html": {
"relative_path": "configuration/toc.html",
"hash": "5NWet+DDp3x4XZo7rfZqjQ=="
"hash": "hEZG047NIeu+o0KUdkadEA=="
}
},
"is_incremental": false,
@@ -7095,6 +7107,73 @@
"is_incremental": false,
"version": ""
},
{
"type": "Conceptual",
"source_relative_path": "guide/choosing-the-right-flow.md",
"output": {
".html": {
"relative_path": "guide/choosing-the-right-flow.html",
"hash": "LQ9W5X4RNfnv0sqhspnTHQ=="
}
},
"is_incremental": false,
"version": ""
},
{
"type": "Resource",
"source_relative_path": "guide/choosing-the-right-flow/authorization-code-flow.png",
"output": {
"resource": {
"relative_path": "guide/choosing-the-right-flow/authorization-code-flow.png"
}
},
"is_incremental": false,
"version": ""
},
{
"type": "Resource",
"source_relative_path": "guide/choosing-the-right-flow/client-credentials-flow.png",
"output": {
"resource": {
"relative_path": "guide/choosing-the-right-flow/client-credentials-flow.png"
}
},
"is_incremental": false,
"version": ""
},
{
"type": "Resource",
"source_relative_path": "guide/choosing-the-right-flow/consent-form.png",
"output": {
"resource": {
"relative_path": "guide/choosing-the-right-flow/consent-form.png"
}
},
"is_incremental": false,
"version": ""
},
{
"type": "Resource",
"source_relative_path": "guide/choosing-the-right-flow/implicit-flow.png",
"output": {
"resource": {
"relative_path": "guide/choosing-the-right-flow/implicit-flow.png"
}
},
"is_incremental": false,
"version": ""
},
{
"type": "Resource",
"source_relative_path": "guide/choosing-the-right-flow/resource-owner-password-flow.png",
"output": {
"resource": {
"relative_path": "guide/choosing-the-right-flow/resource-owner-password-flow.png"
}
},
"is_incremental": false,
"version": ""
},
{
"type": "Conceptual",
"source_relative_path": "guide/getting-started.md",
@@ -7137,7 +7216,7 @@
"output": {
".html": {
"relative_path": "guide/toc.html",
"hash": "yVHEDlC+Qhoq+brhAwUcTA=="
"hash": "cXNBHHPLy0WGdOpsbRiH1w=="
}
},
"is_incremental": false,
@@ -7886,7 +7965,7 @@
"ConceptualDocumentProcessor": {
"can_incremental": false,
"incrementalPhase": "build",
"total_file_count": 128,
"total_file_count": 130,
"skipped_file_count": 0
},
"ManagedReferenceDocumentProcessor": {