702495fe22
Closes #21176 Co-authored-by: andymunro <48995441+andymunro@users.noreply.github.com> Co-authored-by: Stian Thorgersen <stianst@gmail.com>
39 lines
3 KiB
Text
39 lines
3 KiB
Text
=== Recommendations
|
|
|
|
This section describes some recommendations when securing your applications with {project_name}.
|
|
|
|
==== Validating access tokens
|
|
|
|
If you need to manually validate access tokens issued by {project_name}, you can invoke the <<_token_introspection_endpoint,Introspection Endpoint>>.
|
|
The downside to this approach is that you have to make a network invocation to the {project_name} server. This can be slow and possibly overload the
|
|
server if you have too many validation requests going on at the same time. {project_name} issued access tokens are https://datatracker.ietf.org/doc/html/rfc7519[JSON Web Tokens (JWT)] digitally signed and encoded using https://datatracker.ietf.org/doc/html/rfc7515[JSON Web Signature (JWS)].
|
|
Because they are encoded in this way, you can locally validate access tokens using the public key of the issuing realm. You can either hard code the
|
|
realm's public key in your validation code, or lookup and cache the public key using the <<_certificate_endpoint, certificate endpoint>> with the Key ID (KID) embedded within the
|
|
JWS. Depending on what language you code in, many third party libraries exist and they can help you with JWS validation.
|
|
|
|
==== Redirect URIs
|
|
|
|
When using the redirect based flows, be sure to use valid redirect uris for your clients. The redirect uris should be as specific as possible. This
|
|
especially applies to client-side (public clients) applications. Failing to do so could result in:
|
|
|
|
* Open redirects - this can allow attackers to create spoof links that looks like they are coming from your domain
|
|
* Unauthorized entry - when users are already authenticated with {project_name}, an attacker can use a public client where redirect uris have not be configured correctly to gain access by redirecting the user without the users knowledge
|
|
|
|
In production for web applications always use `https` for all redirect URIs. Do not allow redirects to http.
|
|
|
|
A few special redirect URIs also exist:
|
|
|
|
[[_installed_applications_url]]
|
|
`$$http://127.0.0.1$$`::
|
|
|
|
This redirect URI is useful for native applications and allows the native application to create a web server on a random port that can be used to obtain the
|
|
authorization code. This redirect uri allows any port. Note that per https://datatracker.ietf.org/doc/html/rfc8252#section-8.3[OAuth 2.0 for Native Apps], the use of
|
|
`localhost` is *not* recommended and the IP literal `127.0.0.1` should be used instead.
|
|
|
|
[[_installed_applications_urn]]
|
|
`urn:ietf:wg:oauth:2.0:oob`::
|
|
|
|
If you cannot start a web server in the client (or a browser is not available), you can use the special `urn:ietf:wg:oauth:2.0:oob` redirect uri.
|
|
When this redirect uri is used, {project_name} displays a page with the code in the title and in a box on the page.
|
|
The application can either detect that the browser title has changed, or the user can copy and paste the code manually to the application.
|
|
With this redirect uri, a user can use a different device to obtain a code to paste back to the application.
|