<ahref="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),
<ahref="https://tools.ietf.org/html/rfc6749#section-4.3">the resource owner password credentials grant</a> and
<h3id="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 <ahref="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,
</code></pre><divclass="CAUTION"><h5>Caution</h5><p>This flow is <strong>not recommended by the OAuth 2.0 specification</strong> as it'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't be fully trusted by the authorization server</strong>.</p>
<p>While popular and trivial to implement (as it doesn't involve any redirection or consent form and unlike interactive flows, doesn'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't expose passwords to client applications and is not limited to password authentication.</p>
<h3id="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'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>
</code></pre><divclass="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>, <ahref="https://tools.ietf.org/html/rfc6749#section-4.4.2">as required by the OAuth 2.0 specification</a>.</p>
<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'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>
<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
<ahref="https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest">that allows flowing custom data and helps mitigate XSRF attacks</a>.</p>
<divclass="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're using, POST requests might also be supported to allow you to send large authorization requests.
</code></pre><divclass="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't match.
<ahref="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>
<divclass="NOTE"><h5>Note</h5><p>To help the identity provider <ahref="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>
</code></pre><divclass="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
<p>The implicit flow is similar to the authorization code flow, <strong>except there'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>
</code></pre><divclass="CAUTION"><h5>Caution</h5><p>Initially designed for browser applications, this flow is inherently less secure than the authorization code flow and doesn't support
<divclass="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't match.
<ahref="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 <ahref="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>
