mirror of
https://github.com/zitadel/zitadel.git
synced 2025-10-16 12:50:21 +00:00
docs: add tailwindcss for styles, oidc authorize endpoint playground (#4707)
* variable parser * rm plugin * set fcn * env * EnvCode component * cleanup env demo * env * rm remark plugin * auth request context * auth req component * authorize endpoint construction * rev react page * fix endpoint * styling * query params with anchor * desc * tailwind coexistence * fix styles * add login_hint, organizationId scope * auth request without prompt * show login_hint * sync displayed url with actual href * fix fcn * coloring * Update docs/src/components/authrequest.jsx Co-authored-by: mffap <mpa@zitadel.com> * Update docs/src/components/authrequest.jsx Co-authored-by: mffap <mpa@zitadel.com> * Update docs/src/components/authrequest.jsx Co-authored-by: mffap <mpa@zitadel.com> * Update docs/src/components/authrequest.jsx Co-authored-by: mffap <mpa@zitadel.com> * Update docs/src/components/authrequest.jsx Co-authored-by: mffap <mpa@zitadel.com> * Update docs/src/components/authrequest.jsx Co-authored-by: mffap <mpa@zitadel.com> * add plausible, header * add pkce * move * adds pkce code challenge * replace cboa * reaname and move to required * fall back to cboa due to webpack error * trailing slash * reorder org_id * remove resourceowner * texts * update references * buffer, fix some react dom components * Apply suggestions from code review Co-authored-by: Florian Forster <florian@zitadel.com> * standard scopes Co-authored-by: mffap <mpa@zitadel.com> Co-authored-by: Florian Forster <florian@zitadel.com>
This commit is contained in:
@@ -34,7 +34,7 @@ The easiest way to have a look at them is, to import them in the [Swagger Editor
|
||||
The authentication API (aka Auth API) is used for all operations on the currently logged in user. The user id is taken from the sub claim in the token.
|
||||
|
||||
</div>
|
||||
<div class="apicard-right">
|
||||
<div className="apicard-right">
|
||||
|
||||
### GRPC
|
||||
|
||||
@@ -70,7 +70,7 @@ The management API is as the name states the interface where systems can mutate
|
||||
To identify the current organization you can send a header `x-zitadel-orgid` or if no header is set, the organization of the authenticated user is set.
|
||||
|
||||
</div>
|
||||
<div class="apicard-right">
|
||||
<div className="apicard-right">
|
||||
|
||||
### GRPC
|
||||
|
||||
@@ -104,7 +104,7 @@ Definition:
|
||||
This API is intended to configure and manage one ZITADEL instance itself.
|
||||
|
||||
</div>
|
||||
<div class="apicard-right">
|
||||
<div className="apicard-right">
|
||||
|
||||
### GRPC
|
||||
|
||||
@@ -140,7 +140,7 @@ This API is intended to manage the different ZITADEL instances within the system
|
||||
Checkout the guide how to [access the ZITADEL System API](/docs/guides/integrate/access-zitadel-system-api).
|
||||
|
||||
</div>
|
||||
<div class="apicard-right">
|
||||
<div className="apicard-right">
|
||||
|
||||
### GRPC
|
||||
|
||||
@@ -209,9 +209,9 @@ As you can see the `GetMyUser` function is also available as a REST service unde
|
||||
|
||||
In the table below you can see the URI of those calls.
|
||||
|
||||
| Service | URI |
|
||||
| :------ | :--------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| REST | {your_domain}/auth/v1/users/me |
|
||||
| Service | URI |
|
||||
| :------ | :-------------------------------------------------- |
|
||||
| REST | {your_domain}/auth/v1/users/me |
|
||||
| GRPC | {your_domain}/zitadel.auth.v1.AuthService/GetMyUser |
|
||||
|
||||
## Domains
|
||||
|
115
docs/docs/apis/openidoauth/authrequest.mdx
Normal file
115
docs/docs/apis/openidoauth/authrequest.mdx
Normal file
@@ -0,0 +1,115 @@
|
||||
---
|
||||
title: OIDC Authentication Request Playground
|
||||
sidebar_label: OIDC Playground
|
||||
---
|
||||
|
||||
import { SetAuthRequest } from "../../../src/components/authrequest";
|
||||
|
||||
The OIDC Playground is for testing OpenID Authentication Requests, giving you more insight how OpenID Connect works and how you can customize ZITADEL behavior with different parameters.
|
||||
|
||||
An OpenID Connect (OIDC) [authentication request](https://openid.net/specs/openid-connect-core-1_0.html) is an OAuth 2.0 Authorization Request using additional parameters and scopes to request that the end-user be authenticated by ZITADEL.
|
||||
|
||||
<SetAuthRequest />
|
||||
|
||||
## Why this OIDC playground?
|
||||
|
||||
Currently ZITADEL requires human users to authenticate trough the hosted login page.
|
||||
Your application should initiate a login by issuing an authentication request and redirecting the user to the login page. You can customize the behavior of ZITADEL by providing additional parameters and scopes in the request.
|
||||
|
||||
This playground should help you to initially craft an authentication request and to explore the behavior of ZITADEL in more depth.
|
||||
|
||||
## Request parameters explained
|
||||
|
||||
Not all request parameters are available in the playground. Please refer to the full documentation of the [authorization endpoint](/docs/apis/openidoauth/endpoints#authorization_endpoint).
|
||||
|
||||
### Your Domain
|
||||
|
||||
The <span className="text-yellow-500">Instance Domain</span> to your ZITADEL instance. Use the base-path, the playground will add the required path to the request.
|
||||
|
||||
### Required Parameters
|
||||
|
||||
<p>
|
||||
<span className="text-green-500">Client ID</span> is the resource id of an
|
||||
application. It's the application where you want your users to login. You can
|
||||
find the resource id in the Console. When using organization grants, use the
|
||||
client id from the origin organization.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<span className="text-blue-500">Redirect URI</span> be one of the
|
||||
pre-configured redirect uris for your application. You must add the redirect
|
||||
uri for your application, else you will receive an error.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<span className="text-orange-500">Response Type</span> defines whether a
|
||||
code, id_token token or just id_token will be returned. Most use cases will
|
||||
need code.
|
||||
</p>
|
||||
|
||||
More in the <a href="/docs/apis/openidoauth/endpoints#required-request-parameters">documentation</a> about required Parameters.
|
||||
|
||||
### Authentication methods
|
||||
|
||||
Depending on the authentication and authorization flow of your application you might need to append some information to the authentication request.
|
||||
|
||||
<span className="text-teal-600">Authentication method</span> "(none) PKCE" is recommended
|
||||
for most application types. The playground appends automatically a code challenge
|
||||
for PKCE flows.
|
||||
|
||||
You need to append a "Code Challenge" by providing a random <span className="text-teal-600">Code Verifier</span> that is being hashed and encoded in the request to the token endpoint, please see our [guide](/docs/guides/integrate/login-users#token-request) for more details.
|
||||
|
||||
More in the [documentation](/docs/apis/openidoauth/authn-methods) about authentication methods.
|
||||
|
||||
### Additional Parameters
|
||||
|
||||
<p>
|
||||
<span className="text-cyan-500">Prompt</span> defines if and how the user
|
||||
should be prompted on login. For example you can pre-select a login name (
|
||||
<code>select_account</code>) or present the register form (<code>create</code>
|
||||
) to users directly. The value <code>login</code> requires the user to
|
||||
re-authenticate.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<span className="text-rose-500">Login hint</span> must be a valid logon name
|
||||
of a user. You can skip the account picker by providing the Login hint.
|
||||
</p>
|
||||
|
||||
There are many more additional parameters. Please refer to the [documentation](/docs/apis/openidoauth/endpoints#additional-parameters) about additional parameters.
|
||||
|
||||
## Standard Scopes
|
||||
|
||||
Used to request additional information from ZITADEL.
|
||||
These scopes are defined in the OpenID Connect specification.
|
||||
The `openid` scope is mandatory.
|
||||
|
||||
Not all scopes are available in the playground. Please refer to the full [documentation](/docs/apis/openidoauth/scopes) for the exhaustive list of available standard and reserved scopes.
|
||||
|
||||
## Reserved Scopes
|
||||
|
||||
You can request additional information that is specific to ZITADEL or customize the behavior of ZITADEL by including reserved scopes.
|
||||
Please refer to the [documentation](/docs/apis/openidoauth/scopes#reserved-scopes) for a full list of available reserved scopes.
|
||||
|
||||
### Organization policies and branding
|
||||
|
||||
Enforce an organization's policies and branding as well as membership of the user by passing the scope `urn:zitadel:iam:org:id:{id}` with the required <span className="text-purple-500">Organization ID</span>.
|
||||
|
||||
Please refer to the full [guide on branding](/docs/guides/manage/customize/branding).
|
||||
|
||||
### Get user metadata
|
||||
|
||||
Pass the scope `urn:zitadel:iam:user:metadata` to request a user's metadata.
|
||||
Please refer to the full [guide on user-metadata](/docs/guides/manage/customize/user-metadata) for further details.
|
||||
|
||||
### Access core apis
|
||||
|
||||
Calling the [core API](/docs/apis/introduction) with the authenticated user, requires that the projectID of ZITADEL is included in the audience claim.
|
||||
|
||||
This can be achieved by adding the scope `urn:zitadel:iam:org:project:id:zitadel:aud` to your applications authorization request.
|
||||
|
||||
## How to use ZITADEL in your project
|
||||
|
||||
Please refer to our [guide](/docs/guides/integrate/login-users) on how to login users.
|
||||
|
||||
OpenID Connect certified libraries should allow you to customize the parameters and define scopes for the authorization request. You can also continue by using one of our [example applications](/docs/examples/introduction).
|
@@ -2,13 +2,13 @@
|
||||
title: Endpoints
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
import Tabs from "@theme/Tabs";
|
||||
import TabItem from "@theme/TabItem";
|
||||
|
||||
## OpenID Connect 1.0 Discovery
|
||||
|
||||
The OpenID Connect Discovery Endpoint is located within the issuer domain.
|
||||
This would give us {your_domain}/.well-known/openid-configuration.
|
||||
This would give us {your_domain}/.well-known/openid-configuration.
|
||||
|
||||
**Link to spec.** [OpenID Connect Discovery 1.0 incorporating errata set 1](https://openid.net/specs/openid-connect-discovery-1_0.html)
|
||||
|
||||
@@ -21,28 +21,36 @@ The authorization_endpoint is located with the login page, due to the need of ac
|
||||
:::
|
||||
|
||||
The authorization_endpoint is the starting point for all initial user authentications. The user agent (browser) will be redirected to this endpoint to
|
||||
authenticate the user in exchange for an authorization_code (authorization code flow) or tokens (implicit flow).
|
||||
authenticate the user in exchange for an authorization_code (authorization code flow) or tokens (implicit flow).
|
||||
|
||||
<details>
|
||||
<summary>Links to specs</summary>
|
||||
<ul>
|
||||
<li><a href="https://datatracker.ietf.org/doc/html/rfc6749#section-3.1">Section 3.1 of OAuth2.0 (RFC6749)</a></li>
|
||||
<li><a href="https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint">Section 3.1.2 of OpenID Connect Core 1.0 incorporating errata set 1</a></li>
|
||||
</ul>
|
||||
<summary>Links to specs</summary>
|
||||
<ul>
|
||||
<li>
|
||||
<a href="https://datatracker.ietf.org/doc/html/rfc6749#section-3.1">
|
||||
Section 3.1 of OAuth2.0 (RFC6749)
|
||||
</a>
|
||||
</li>
|
||||
<li>
|
||||
<a href="https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint">
|
||||
Section 3.1.2 of OpenID Connect Core 1.0 incorporating errata set 1
|
||||
</a>
|
||||
</li>
|
||||
</ul>
|
||||
</details>
|
||||
|
||||
### Required request parameters
|
||||
|
||||
| Parameter | Description |
|
||||
|---------------|---------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| client_id | The id of your client as shown in Console. |
|
||||
| redirect_uri | Callback uri of the authorization request where the code or tokens will be sent to. Must match exactly one of the preregistered in Console. |
|
||||
| response_type | Determines whether a `code`, `id_token token` or just `id_token` will be returned. Most use cases will need `code`. See flow guide for more info. |
|
||||
| scope | `openid` is required, see [Scopes](scopes) for more possible values. Scopes are space delimited, e.g. `openid email profile` |
|
||||
|
||||
:::important
|
||||
Following the [OIDC Core 1.0 specs](https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims) whenever an access_token is issued,
|
||||
the id_token will not contain any claims of the scopes `profile`, `email`, `phone` and `address`.
|
||||
Following the [OIDC Core 1.0 specs](https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims) whenever an access_token is issued,
|
||||
the id_token will not contain any claims of the scopes `profile`, `email`, `phone` and `address`.
|
||||
|
||||
Send the access_token to the [userinfo_endpoint](#userinfo_endpoint) or [introspection_endpoint](#introspection_endpoint) the retrieve these claims
|
||||
or set the `id_token_userinfo_assertion` Option ("User Info inside ID Token" in Console) to true.
|
||||
@@ -69,7 +77,7 @@ no additional parameters required
|
||||
<TabItem value="none">
|
||||
|
||||
| Parameter | Description |
|
||||
|-----------------------|-------------------------------------------------------|
|
||||
| --------------------- | ----------------------------------------------------- |
|
||||
| code_challenge | The SHA-256 value of the generated `code_verifier` |
|
||||
| code_challenge_method | Method used to generate the challenge, must be `S256` |
|
||||
|
||||
@@ -84,7 +92,7 @@ no additional parameters required
|
||||
### Additional parameters
|
||||
|
||||
| Parameter | Description |
|
||||
|---------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| id_token_hint | Valid `id_token` (of an existing session) used to identity the subject. **SHOULD** be provided when using prompt `none`. |
|
||||
| login_hint | A valid logon name of a user. Will be used for username inputs or preselecting a user on `select_account`. Be sure to encode the hint correctly using url encoding (especially when using `+` or alike in the loginname) |
|
||||
| max_age | Seconds since the last active successful authentication of the user |
|
||||
@@ -95,10 +103,10 @@ no additional parameters required
|
||||
|
||||
### Successful Code Response
|
||||
|
||||
When your `response_type` was `code` and no error occurred, the following response will be returned:
|
||||
When your `response_type` was `code` and no error occurred, the following response will be returned:
|
||||
|
||||
| Property | Description |
|
||||
|----------|-------------------------------------------------------------------------------|
|
||||
| -------- | ----------------------------------------------------------------------------- |
|
||||
| code | Opaque string which will be necessary to request tokens on the token endpoint |
|
||||
| state | Unmodified `state` parameter from the request |
|
||||
|
||||
@@ -107,7 +115,7 @@ When your `response_type` was `code` and no error occurred, the following respon
|
||||
When your `response_type` was either `it_token` or `id_token token` and no error occurred, the following response will be returned:
|
||||
|
||||
| Property | Description |
|
||||
|--------------|---------------------------------------------------------------------------------------|
|
||||
| ------------ | ------------------------------------------------------------------------------------- |
|
||||
| access_token | Only returned if `response_type` included `token` |
|
||||
| expires_in | Number of second until the expiration of the `access_token` |
|
||||
| id_token | An `id_token` of the authorized user |
|
||||
@@ -125,7 +133,7 @@ the error will be display directly to the user on the auth server
|
||||
:::
|
||||
|
||||
| Property | Description |
|
||||
|-------------------|----------------------------------------------------------------------|
|
||||
| ----------------- | -------------------------------------------------------------------- |
|
||||
| error | An OAuth / OIDC [error_type](#authorize-errors) |
|
||||
| error_description | Description of the error type or additional information of the error |
|
||||
| state | Unmodified `state` parameter from the request |
|
||||
@@ -133,7 +141,7 @@ the error will be display directly to the user on the auth server
|
||||
#### Possible errors {#authorize-errors}
|
||||
|
||||
| error_type | Possible reason |
|
||||
|---------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| invalid_request | The request is missing a required parameter, includes an invalid parameter value, includes a parameter more than once, or is otherwise malformed. |
|
||||
| invalid_scope | The requested scope is invalid. Typically the required `openid` value is missing. |
|
||||
| unauthorized_client | The client is not authorized to request an access_token using this method. Check in Console that the requested `response_type` is allowed in your application configuration. |
|
||||
@@ -142,12 +150,11 @@ the error will be display directly to the user on the auth server
|
||||
| interaction_required | The authorization server requires end-user interaction of some form to proceed. This error MAY be returned when the prompt parameter value in the Authentication Request is none, but the Authentication Request cannot be completed without displaying a user interface for end-user interaction. |
|
||||
| login_required | The authorization server requires end-user authentication. This error MAY be returned when the prompt parameter value in the Authentication Request is none, but the Authentication Request cannot be completed without displaying a user interface for end-user authentication. |
|
||||
|
||||
|
||||
## token_endpoint
|
||||
|
||||
{your_domain}/oauth/v2/token
|
||||
|
||||
The token_endpoint will as the name suggests return various tokens (access, id and refresh) depending on the used `grant_type`.
|
||||
The token_endpoint will as the name suggests return various tokens (access, id and refresh) depending on the used `grant_type`.
|
||||
When using [`authorization_code`](#authorization-code-grant-code-exchange) flow call this endpoint after receiving the code from the authorization_endpoint.
|
||||
When using [`refresh_token`](#authorization-code-grant-code-exchange) or [`urn:ietf:params:oauth:grant-type:jwt-bearer` (JWT Profile)](#jwt-profile-grant) you will call this endpoint directly.
|
||||
|
||||
@@ -158,7 +165,7 @@ As mention above, when using `authorization_code` grant, this endpoint will be y
|
||||
#### Required request Parameters
|
||||
|
||||
| Parameter | Description |
|
||||
|--------------|---------------------------------------------------------------------------------------------------------------|
|
||||
| ------------ | ------------------------------------------------------------------------------------------------------------- |
|
||||
| code | Code that was issued from the authorization request. |
|
||||
| grant_type | Must be `authorization_code` |
|
||||
| redirect_uri | Callback uri where the code was be sent to. Must match exactly the redirect_uri of the authorization request. |
|
||||
@@ -185,7 +192,7 @@ Send your `client_id` and `client_secret` as Basic Auth Header. Check [Client Se
|
||||
Send your `client_id` and `client_secret` as parameters in the body:
|
||||
|
||||
| Parameter | Description |
|
||||
|---------------|----------------------------------|
|
||||
| ------------- | -------------------------------- |
|
||||
| client_id | client_id of the application |
|
||||
| client_secret | client_secret of the application |
|
||||
|
||||
@@ -195,7 +202,7 @@ Send your `client_id` and `client_secret` as parameters in the body:
|
||||
Send your `code_verifier` for us to recompute the `code_challenge` of the authorization request.
|
||||
|
||||
| Parameter | Description |
|
||||
|---------------|--------------------------------------------------------------|
|
||||
| ------------- | ------------------------------------------------------------ |
|
||||
| code_verifier | code_verifier previously used to generate the code_challenge |
|
||||
|
||||
</TabItem>
|
||||
@@ -204,7 +211,7 @@ Send your `code_verifier` for us to recompute the `code_challenge` of the author
|
||||
Send a client assertion as JWT for us to validate the signature against the registered public key.
|
||||
|
||||
| Parameter | Description |
|
||||
|-----------------------|--------------------------------------------------------------------------------------------------------------|
|
||||
| --------------------- | ------------------------------------------------------------------------------------------------------------ |
|
||||
| client_assertion | JWT built and signed according to [Using JWTs for Client Authentication](authn-methods#jwt-with-private-key) |
|
||||
| client_assertion_type | Must be `urn:ietf:params:oauth:client-assertion-type:jwt-bearer` |
|
||||
|
||||
@@ -214,7 +221,7 @@ Send a client assertion as JWT for us to validate the signature against the regi
|
||||
#### Successful code response {#token-code-response}
|
||||
|
||||
| Property | Description |
|
||||
|---------------|---------------------------------------------------------------------------------------|
|
||||
| ------------- | ------------------------------------------------------------------------------------- |
|
||||
| access_token | An `access_token` as JWT or opaque token |
|
||||
| expires_in | Number of second until the expiration of the `access_token` |
|
||||
| id_token | An `id_token` of the authorized user |
|
||||
@@ -227,7 +234,7 @@ Send a client assertion as JWT for us to validate the signature against the regi
|
||||
#### Required request Parameters
|
||||
|
||||
| Parameter | Description |
|
||||
|------------|-------------------------------------------------------------------------------------------------------------------------|
|
||||
| ---------- | ----------------------------------------------------------------------------------------------------------------------- |
|
||||
| grant_type | Must be `urn:ietf:params:oauth:grant-type:jwt-bearer` |
|
||||
| assertion | JWT built and signed according to [Using JWTs for Authorization Grants](grant-types#using-jwts-as-authorization-grants) |
|
||||
| scope | [Scopes](scopes) you would like to request from ZITADEL. Scopes are space delimited, e.g. `openid email profile` |
|
||||
@@ -243,7 +250,7 @@ curl --request POST \
|
||||
#### Successful JWT Profile response {#token-jwt-response}
|
||||
|
||||
| Property | Description |
|
||||
|--------------|---------------------------------------------------------------------------------------|
|
||||
| ------------ | ------------------------------------------------------------------------------------- |
|
||||
| access_token | An `access_token` as JWT or opaque token |
|
||||
| expires_in | Number of second until the expiration of the `access_token` |
|
||||
| id_token | An `id_token` of the authorized service user |
|
||||
@@ -252,13 +259,13 @@ curl --request POST \
|
||||
|
||||
### Refresh Token Grant
|
||||
|
||||
To request a new `access_token` without user interaction, you can use the `refresh_token` grant.
|
||||
To request a new `access_token` without user interaction, you can use the `refresh_token` grant.
|
||||
See [offline_access Scope](scopes#standard-scopes) for how to request a `refresh_token` in the authorization request.
|
||||
|
||||
#### Required request Parameters
|
||||
|
||||
| Parameter | Description |
|
||||
|---------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| grant_type | Must be `refresh_token` |
|
||||
| refresh_token | The refresh_token previously issued in the last authorization_code or refresh_token request. |
|
||||
| scope | [Scopes](scopes) you would like to request from ZITADEL for the new access_token. Must be a subset of the scope originally requested by the corresponding auth request. When omitted, the scopes requested by the original auth request will be reused. Scopes are space delimited, e.g. `openid email profile` |
|
||||
@@ -285,7 +292,7 @@ Send your `client_id` and `client_secret` as Basic Auth Header. Check [Client Se
|
||||
Send your `client_id` and `client_secret` as parameters in the body:
|
||||
|
||||
| Parameter | Description |
|
||||
|---------------|----------------------------------|
|
||||
| ------------- | -------------------------------- |
|
||||
| client_id | client_id of the application |
|
||||
| client_secret | client_secret of the application |
|
||||
|
||||
@@ -300,7 +307,7 @@ Send your `client_id` as parameter in the body. No authentication is required.
|
||||
Send a `client_assertion` as JWT for us to validate the signature against the registered public key.
|
||||
|
||||
| Parameter | Description |
|
||||
|-----------------------|--------------------------------------------------------------------------------------------------------------|
|
||||
| --------------------- | ------------------------------------------------------------------------------------------------------------ |
|
||||
| client_assertion | JWT built and signed according to [Using JWTs for Client Authentication](authn-methods#jwt-with-private-key) |
|
||||
| client_assertion_type | Must be `urn:ietf:params:oauth:client-assertion-type:jwt-bearer` |
|
||||
|
||||
@@ -310,7 +317,7 @@ Send a `client_assertion` as JWT for us to validate the signature against the re
|
||||
#### Successful refresh token response {#token-refresh-response}
|
||||
|
||||
| Property | Description |
|
||||
|---------------|---------------------------------------------------------------------------------------|
|
||||
| ------------- | ------------------------------------------------------------------------------------- |
|
||||
| access_token | An `access_token` as JWT or opaque token |
|
||||
| expires_in | Number of second until the expiration of the `access_token` |
|
||||
| id_token | An `id_token` of the authorized user |
|
||||
@@ -321,7 +328,7 @@ Send a `client_assertion` as JWT for us to validate the signature against the re
|
||||
### Error response
|
||||
|
||||
| error_type | Possible reason |
|
||||
|------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| invalid_request | The request is missing a required parameter, includes an unsupported parameter value (other than grant type), repeats a parameter, includes multiple credentials, utilizes more than one mechanism for authenticating the client, or is otherwise malformed. |
|
||||
| invalid_scope | The requested scope is invalid, unknown, malformed, or exceeds the scope granted by the resource owner. |
|
||||
| unauthorized_client | The authenticated client is not authorized to use this authorization grant type. |
|
||||
@@ -338,7 +345,7 @@ This endpoint enables clients to validate an `acccess_token`, either opaque or J
|
||||
this endpoint will check if the token is not revoked (by client or logout).
|
||||
|
||||
| Parameter | Description |
|
||||
|-----------|-----------------|
|
||||
| --------- | --------------- |
|
||||
| token | An access token |
|
||||
|
||||
Depending on your authorization method you will have to provide additional parameters or headers:
|
||||
@@ -370,7 +377,7 @@ curl --request POST \
|
||||
Send a `client_assertion` as JWT for us to validate the signature against the registered public key.
|
||||
|
||||
| Parameter | Description |
|
||||
|-----------------------|-------------------------------------------------------------------------------------------------------------|
|
||||
| --------------------- | ----------------------------------------------------------------------------------------------------------- |
|
||||
| client_assertion | JWT built and signed according to [Using JWTs for Client Authentication](authn-methods#client-secret-basic) |
|
||||
| client_assertion_type | must be `urn:ietf:params:oauth:client-assertion-type:jwt-bearer` |
|
||||
|
||||
@@ -388,25 +395,25 @@ curl --request POST \
|
||||
|
||||
### Successful introspection response {#introspect-response}
|
||||
|
||||
Upon successful authorization of the client a response with the boolean `active` is returned, indicating if the provided token
|
||||
Upon successful authorization of the client a response with the boolean `active` is returned, indicating if the provided token
|
||||
is active and the requesting client is part of the token audience.
|
||||
|
||||
If `active` is **true**, further information will be provided:
|
||||
|
||||
| Property | Description |
|
||||
|------------|------------------------------------------------------------------------|
|
||||
| aud | The audience of the token |
|
||||
| client_id | The client_id of the application the token was issued to |
|
||||
| exp | Time the token expires (as unix time) |
|
||||
| iat | Time of the token was issued at (as unix time) |
|
||||
| iss | Issuer of the token |
|
||||
| jti | Unique id of the token |
|
||||
| nbf | Time the token must not be used before (as unix time) |
|
||||
| scope | Space delimited list of scopes granted to the token |
|
||||
| token_type | Type of the inspected token. Value is always `Bearer` |
|
||||
| username | ZITADEL's login name of the user. Consist of `username@primarydomain` |
|
||||
| Property | Description |
|
||||
| ---------- | --------------------------------------------------------------------- |
|
||||
| aud | The audience of the token |
|
||||
| client_id | The client_id of the application the token was issued to |
|
||||
| exp | Time the token expires (as unix time) |
|
||||
| iat | Time of the token was issued at (as unix time) |
|
||||
| iss | Issuer of the token |
|
||||
| jti | Unique id of the token |
|
||||
| nbf | Time the token must not be used before (as unix time) |
|
||||
| scope | Space delimited list of scopes granted to the token |
|
||||
| token_type | Type of the inspected token. Value is always `Bearer` |
|
||||
| username | ZITADEL's login name of the user. Consist of `username@primarydomain` |
|
||||
|
||||
Additionally and depending on the granted scopes, information about the authorized user is provided.
|
||||
Additionally and depending on the granted scopes, information about the authorized user is provided.
|
||||
Check the [Claims](claims) page if a specific claims might be returned and for detailed description.
|
||||
|
||||
### Error response {#introspect-error-response}
|
||||
@@ -420,6 +427,7 @@ If the authorization fails, an HTTP 401 with `invalid_client` will be returned.
|
||||
This endpoint will return information about the authorized user.
|
||||
|
||||
Send the `access_token` of the **user** (not the client) as Bearer Token in the `authorization` header:
|
||||
|
||||
```BASH
|
||||
curl --request GET \
|
||||
--url {your_domain}/oidc/v1/userinfo
|
||||
@@ -446,9 +454,8 @@ If you revoke an `access_token` only the specific token will be revoked. When re
|
||||
the corresponding `access_token` will be revoked as well.
|
||||
:::
|
||||
|
||||
|
||||
| Parameter | Description |
|
||||
|-----------|----------------------------------|
|
||||
| --------- | -------------------------------- |
|
||||
| token | An access token or refresh token |
|
||||
|
||||
Depending on your authorization method you will have to provide additional parameters or headers:
|
||||
@@ -473,7 +480,7 @@ Send your `client_id` and `client_secret` as Basic Auth Header. Check [Client Se
|
||||
Send your `client_id` and `client_secret` as parameters in the body:
|
||||
|
||||
| Parameter | Description |
|
||||
|---------------|----------------------------------|
|
||||
| ------------- | -------------------------------- |
|
||||
| client_id | client_id of the application |
|
||||
| client_secret | client_secret of the application |
|
||||
|
||||
@@ -483,7 +490,7 @@ Send your `client_id` and `client_secret` as parameters in the body:
|
||||
Send your `client_id` as parameters in the body:
|
||||
|
||||
| Parameter | Description |
|
||||
|-----------|------------------------------|
|
||||
| --------- | ---------------------------- |
|
||||
| client_id | client_id of the application |
|
||||
|
||||
</TabItem>
|
||||
@@ -492,7 +499,7 @@ Send your `client_id` as parameters in the body:
|
||||
Send a `client_assertion` as JWT for ZITADEL to verify the signature against the registered public key.
|
||||
|
||||
| Parameter | Description |
|
||||
|-----------------------|---------------------------------------------------------------------------------------------------------------|
|
||||
| --------------------- | ------------------------------------------------------------------------------------------------------------- |
|
||||
| client_assertion | JWT created and signed according to [Using JWTs for Client Authentication](authn-methods#client-secret-basic) |
|
||||
| client_assertion_type | must be `urn:ietf:params:oauth:client-assertion-type:jwt-bearer` |
|
||||
|
||||
@@ -514,10 +521,10 @@ curl --request POST \
|
||||
|
||||
The endpoint has to be opened in the user agent (browser) to terminate the user sessions.
|
||||
|
||||
No parameters are needed apart from the user agent cookie, but you can provide the following to customize the behaviour:
|
||||
No parameters are needed apart from the user agent cookie, but you can provide the following to customize the behaviour:
|
||||
|
||||
| Parameter | Description |
|
||||
|--------------------------|----------------------------------------------------------------------------------------------------------------------------------|
|
||||
| ------------------------ | -------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| id_token_hint | the id_token that was previously issued to the client |
|
||||
| client_id | client_id of the application |
|
||||
| post_logout_redirect_uri | Callback uri of the logout where the user (agent) will be redirected to. Must match exactly one of the preregistered in Console. |
|
Reference in New Issue
Block a user