zitadel/03-openidoauth.en.md at 78c0cf2f57214086ab4ed33d4da1ef26635f2ce9

mirror of https://github.com/zitadel/zitadel.git synced 2024-12-12 19:14:23 +00:00

fix: add and verified projectID in audience (#957 )

* feat: new scope for project id in aud

* feat: add doc

* feat: projectid endpoint

* feat: remove handle Proejct id

* fix: remove go.mod replace

* fix: add project id to aud

* fix: update oidc version

* fix: change project id scope

* update projectID scope to current usage

* typo: ZITADEL uppercase

Co-authored-by: Livio Amstutz <livio.a@gmail.com>

2020-11-16 10:54:48 +01:00

8.3 KiB

Raw Blame History

title
OpenID Connect 1.0 & OAuth 2.0

Endpoints and Domains

This chapter documents the OpenID Connect 1.0 and OAuth 2.0 features provided by ZITADEL.

Under normal circumstances ZITADEL need four domain names to operate properly.

Domain Name	Example	Description
issuer	issuer.zitadel.ch	Provides the OpenID Connect 1.0 Discovery Endpoint
api	api.zitadel.ch	All ZITADEL API's are located under this domain see API explanation for details
login	accounts.zitadel.ch	The accounts.* page provides server renderer pages like login and register and as well the authorization_endpoint for OpenID Connect
console	console.zitadel.ch	With the console.* domain we serve the assets for the management gui

OpenID Connect 1.0 Discovery

The OpenID Connect Discovery Endpoint is located within the issuer domain. For example with zitadel.ch this would be the domain issuer.zitadel.ch. This would give us https://issuer.zitadel.ch/.well-known/openid-configuration.

Link to spec. OpenID Connect Discovery 1.0 incorporating errata set 1

authorization_endpoint

https://accounts.zitadel.ch/oauth/v2/authorize

The authorization_endpoint is located with the login page, due to the need of accessing the same cookie domain

The end_session_endpoint is located with the login page, due to the need of accessing the same cookie domain

jwks_uri

https://api.zitadel.ch/oauth/v2/keys

Be aware that these keys can be rotated without any prior notice. We will however make sure that a proper kid is set with each key!

OAuth 2.0 Metadata

ZITADEL does not provide a OAuth 2.0 Metadata endpoint but instead provides a OpenID Connect Discovery Endpoint.

Scopes

How scopes work

TODO describe

Reserved Scopes

In addition to the standard compliant scopes we utilize the following scopes.

Scope	Description	Example
urn:zitadel:iam:org:project:role:{rolename}	By using this scope a client can request the claim urn:zitadel:iam:roles:rolename} to be asserted when possible. As an alternative approach you can enable all roles to be asserted from the project a client belongs to. See details here	urn:zitadel:iam:org:project:role:user
urn:zitadel:iam:org:domain:primary:{domainname}	When requesting this scope ZITADEL will enforce that the user is a member of the selected organisation. If the organisation does not exist a failure is displayed	urn:zitadel:iam:org:domain:primary:acme.ch
urn:zitadel:iam:role:{rolename}
urn:zitadel:iam:org:project🆔{projectid}:aud	By adding this scope, the requested projectid will be added to the audience of the access and id token	ZITADEL Project: urn:zitadel:iam:org:project🆔69234237810729019:aud

Claims

TODO describe

Reserved Claims

Claims	Description	Example
urn:zitadel:iam:org:domain:primary:{domainname}		`{"urn:zitadel:iam:org:domain:primary": "acme.ch"}`
urn:zitadel:iam:org:project:roles:{rolename}		`{"urn:zitadel:iam:org:project:roles": [ {"user": {"id1": "acme.zitade.ch", "id2": "caos.ch"} } ] }`
urn:zitadel:iam:roles:{rolename}

Grant Types

For a list of supported or unsupported Grant Types please have a look at the table below.

Grant Type	Supported
Authorization Code	yes
Authorization Code with PKCE	yes
Implicit	yes
Resource Owner Password Credentials	no
Client Credentials	yes
Device Authorization	under consideration
Refresh Token	work in progress
JSON Web Token (JWT) Profile	partially
Security Assertion Markup Language (SAML) 2.0 Profile	no
Token Exchange	work in progress