TheArchive/zitadel
1
0
Fork 0
mirror of https://github.com/zitadel/zitadel.git synced 2025-08-11 19:07:30 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: generate admin api (#1584)

Browse Source 
* fix: generate admin api

* fix: generate admin api

* fix: generate admin api

* fix: http option

* fix: admin api

* fix: md files

* fix: correct headers

* fix: proto definitions

* fix: proto api

* fix: proto api

* fix: proto api

* fix: proto api
This commit is contained in:
Fabi
2021-04-15 18:21:46 +02:00
committed by GitHub
parent 22feab63da
commit c2fedbbfc6
34 changed files with 8890 additions and 51 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
docs/docs/apis/admin.md
View File

@@ -1,3 +0,0 @@
---
title: Administration
---

45
docs/docs/apis/apis.md Normal file
View File

@@ -0,0 +1,45 @@
---
title: ZITADEL APIs
---
All of our APIs are generated by proto defintions. You can find all the proto definitions in the [Proto API Definitions](proto/auth).
> More about [Protocol Buffer](https://developers.google.com/protocol-buffers)
## Authentication API aka Auth
The authentication API (aka Auth API) is used for all operations on the currently logged in user.
| Service | URI |
|:--------|:----------------------------------------------------------------------------------------------------------------------------|
| REST | [https://api.zitadel.ch/auth/v1/](https://api.zitadel.ch/auth/v1/) |
| GRPC | [https://api.zitadel.ch/caos.zitadel.auth.api.v1.AuthService/](https://api.zitadel.ch/caos.zitadel.auth.api.v1.AuthService) |
> At a later date we might expose functions to build your own login GUI
> You can build your own user Register GUI already by utilizing the [Management API](#management)
[Latest API Version](https://github.com/caos/zitadel/blob/main/proto/zitadel/auth.proto)
## Management API
The management API is as the name states the interface where systems can mutate IAM objects like, organisations, projects, clients, users and so on if they have the necessary access rights.
| Service | URI |
|:--------|:----------------------------------------------------------------------------------------------------------------------------------------------------|
| REST | [https://api.zitadel.ch/management/v1/](https://api.zitadel.ch/management/v1/) |
| GRPC | [https://api.zitadel.ch/caos.zitadel.management.api.v1.ManagementService/](https://api.zitadel.ch/caos.zitadel.management.api.v1.ManagementService) |
[Latest API Version](https://github.com/caos/zitadel/blob/main/proto/zitadel/management.proto)
## Administration API aka Admin
This API is intended to configure and manage the IAM itself.
| Service | URI |
|:--------|:--------------------------------------------------------------------------------------------------------------------------------|
| REST | [https://api.zitadel.ch/admin/v1/](https://api.zitadel.ch/admin/v1/) |
| GRPC | [https://api.zitadel.ch/caos.zitadel.admin.api.v1.AdminService/](https://api.zitadel.ch/caos.zitadel.admin.api.v1.AdminService) |
[Latest

3
docs/docs/apis/authn.md
View File

@@ -1,3 +0,0 @@
---
title: Authentication
---

2
docs/docs/apis/introduction.md
View File

@@ -4,7 +4,7 @@ title: Introduction
> All documentations are under active work and subject to change soon!
### APIs
## APIs
---

3
docs/docs/apis/mgmt.md
View File

@@ -1,3 +0,0 @@
---
title: Management
---

1766
docs/docs/apis/proto/admin.md Normal file
View File

File diff suppressed because it is too large Load Diff

106
docs/docs/apis/proto/app.md Normal file
View File

@@ -0,0 +1,106 @@
---
title: zitadel/app.proto
---
> This document reflects the state from API 1.0 (available from 20.04.2021)
## Enums
### APIAuthMethodType {#apiauthmethodtype}
| Name | Number | Description |
| ---- | ------ | ----------- |
| API_AUTH_METHOD_TYPE_BASIC | 0 | - |
| API_AUTH_METHOD_TYPE_PRIVATE_KEY_JWT | 1 | - |
### AppState {#appstate}
| Name | Number | Description |
| ---- | ------ | ----------- |
| APP_STATE_UNSPECIFIED | 0 | - |
| APP_STATE_ACTIVE | 1 | - |
| APP_STATE_INACTIVE | 2 | - |
### OIDCAppType {#oidcapptype}
| Name | Number | Description |
| ---- | ------ | ----------- |
| OIDC_APP_TYPE_WEB | 0 | - |
| OIDC_APP_TYPE_USER_AGENT | 1 | - |
| OIDC_APP_TYPE_NATIVE | 2 | - |
### OIDCAuthMethodType {#oidcauthmethodtype}
| Name | Number | Description |
| ---- | ------ | ----------- |
| OIDC_AUTH_METHOD_TYPE_BASIC | 0 | - |
| OIDC_AUTH_METHOD_TYPE_POST | 1 | - |
| OIDC_AUTH_METHOD_TYPE_NONE | 2 | - |
| OIDC_AUTH_METHOD_TYPE_PRIVATE_KEY_JWT | 3 | - |
### OIDCGrantType {#oidcgranttype}
| Name | Number | Description |
| ---- | ------ | ----------- |
| OIDC_GRANT_TYPE_AUTHORIZATION_CODE | 0 | - |
| OIDC_GRANT_TYPE_IMPLICIT | 1 | - |
| OIDC_GRANT_TYPE_REFRESH_TOKEN | 2 | - |
### OIDCResponseType {#oidcresponsetype}
| Name | Number | Description |
| ---- | ------ | ----------- |
| OIDC_RESPONSE_TYPE_CODE | 0 | - |
| OIDC_RESPONSE_TYPE_ID_TOKEN | 1 | - |
| OIDC_RESPONSE_TYPE_ID_TOKEN_TOKEN | 2 | - |
### OIDCTokenType {#oidctokentype}
| Name | Number | Description |
| ---- | ------ | ----------- |
| OIDC_TOKEN_TYPE_BEARER | 0 | - |
| OIDC_TOKEN_TYPE_JWT | 1 | - |
### OIDCVersion {#oidcversion}
| Name | Number | Description |
| ---- | ------ | ----------- |
| OIDC_VERSION_1_0 | 0 | - |

1116
docs/docs/apis/proto/auth.md Normal file
View File

File diff suppressed because it is too large Load Diff

24
docs/docs/apis/proto/auth_n_key.md Normal file
View File

@@ -0,0 +1,24 @@
---
title: zitadel/auth_n_key.proto
---
> This document reflects the state from API 1.0 (available from 20.04.2021)
## Enums
### KeyType {#keytype}
| Name | Number | Description |
| ---- | ------ | ----------- |
| KEY_TYPE_UNSPECIFIED | 0 | - |
| KEY_TYPE_JSON | 1 | - |

10
docs/docs/apis/proto/change.md Normal file
View File

@@ -0,0 +1,10 @@
---
title: zitadel/change.proto
---
> This document reflects the state from API 1.0 (available from 20.04.2021)

25
docs/docs/apis/proto/features.md Normal file
View File

@@ -0,0 +1,25 @@
---
title: zitadel/features.proto
---
## Enums
### FeaturesState {#featuresstate}
| Name | Number | Description |
| ---- | ------ | ----------- |
| FEATURES_STATE_ACTIVE | 0 | - |
| FEATURES_STATE_ACTION_REQUIRED | 1 | - |
| FEATURES_STATE_CANCELED | 2 | - |
| FEATURES_STATE_GRANDFATHERED | 3 | - |

82
docs/docs/apis/proto/idp.md Normal file
View File

@@ -0,0 +1,82 @@
---
title: zitadel/idp.proto
---
> This document reflects the state from API 1.0 (available from 20.04.2021)
## Enums
### IDPFieldName {#idpfieldname}
| Name | Number | Description |
| ---- | ------ | ----------- |
| IDP_FIELD_NAME_UNSPECIFIED | 0 | - |
| IDP_FIELD_NAME_NAME | 1 | - |
### IDPOwnerType {#idpownertype}
the owner of the identity provider.
| Name | Number | Description |
| ---- | ------ | ----------- |
| IDP_OWNER_TYPE_UNSPECIFIED | 0 | - |
| IDP_OWNER_TYPE_SYSTEM | 1 | system is managed by the ZITADEL administrators |
| IDP_OWNER_TYPE_ORG | 2 | org is managed by de organisation administrators |
### IDPState {#idpstate}
| Name | Number | Description |
| ---- | ------ | ----------- |
| IDP_STATE_UNSPECIFIED | 0 | - |
| IDP_STATE_ACTIVE | 1 | - |
| IDP_STATE_INACTIVE | 2 | - |
### IDPStylingType {#idpstylingtype}
| Name | Number | Description |
| ---- | ------ | ----------- |
| STYLING_TYPE_UNSPECIFIED | 0 | - |
| STYLING_TYPE_GOOGLE | 1 | - |
### IDPType {#idptype}
authorization framework of the identity provider
| Name | Number | Description |
| ---- | ------ | ----------- |
| IDP_TYPE_UNSPECIFIED | 0 | - |
| IDP_TYPE_OIDC | 1 | PLANNED: IDP_TYPE_SAML |
### OIDCMappingField {#oidcmappingfield}
| Name | Number | Description |
| ---- | ------ | ----------- |
| OIDC_MAPPING_FIELD_UNSPECIFIED | 0 | - |
| OIDC_MAPPING_FIELD_PREFERRED_USERNAME | 1 | - |
| OIDC_MAPPING_FIELD_EMAIL | 2 | - |

5174
docs/docs/apis/proto/management.md Normal file
View File

File diff suppressed because it is too large Load Diff

10
docs/docs/apis/proto/member.md Normal file
View File

@@ -0,0 +1,10 @@
---
title: zitadel/member.proto
---
> This document reflects the state from API 1.0 (available from 20.04.2021)

10
docs/docs/apis/proto/message.md Normal file
View File

@@ -0,0 +1,10 @@
---
title: zitadel/message.proto
---
> This document reflects the state from API 1.0 (available from 20.04.2021)

30
docs/docs/apis/proto/object.md Normal file
View File

@@ -0,0 +1,30 @@
---
title: zitadel/object.proto
---
> This document reflects the state from API 1.0 (available from 20.04.2021)
## Enums
### TextQueryMethod {#textquerymethod}
| Name | Number | Description |
| ---- | ------ | ----------- |
| TEXT_QUERY_METHOD_EQUALS | 0 | - |
| TEXT_QUERY_METHOD_EQUALS_IGNORE_CASE | 1 | - |
| TEXT_QUERY_METHOD_STARTS_WITH | 2 | - |
| TEXT_QUERY_METHOD_STARTS_WITH_IGNORE_CASE | 3 | - |
| TEXT_QUERY_METHOD_CONTAINS | 4 | - |
| TEXT_QUERY_METHOD_CONTAINS_IGNORE_CASE | 5 | - |
| TEXT_QUERY_METHOD_ENDS_WITH | 6 | - |
| TEXT_QUERY_METHOD_ENDS_WITH_IGNORE_CASE | 7 | - |

10
docs/docs/apis/proto/options.md Normal file
View File

@@ -0,0 +1,10 @@
---
title: zitadel/options.proto
---
> This document reflects the state from API 1.0 (available from 20.04.2021)

48
docs/docs/apis/proto/org.md Normal file
View File

@@ -0,0 +1,48 @@
---
title: zitadel/org.proto
---
> This document reflects the state from API 1.0 (available from 20.04.2021)
## Enums
### DomainValidationType {#domainvalidationtype}
| Name | Number | Description |
| ---- | ------ | ----------- |
| DOMAIN_VALIDATION_TYPE_UNSPECIFIED | 0 | - |
| DOMAIN_VALIDATION_TYPE_HTTP | 1 | - |
| DOMAIN_VALIDATION_TYPE_DNS | 2 | - |
### OrgFieldName {#orgfieldname}
| Name | Number | Description |
| ---- | ------ | ----------- |
| ORG_FIELD_NAME_UNSPECIFIED | 0 | - |
| ORG_FIELD_NAME_NAME | 1 | - |
### OrgState {#orgstate}
| Name | Number | Description |
| ---- | ------ | ----------- |
| ORG_STATE_UNSPECIFIED | 0 | - |
| ORG_STATE_ACTIVE | 1 | - |
| ORG_STATE_INACTIVE | 2 | - |

47
docs/docs/apis/proto/policy.md Normal file
View File

@@ -0,0 +1,47 @@
---
title: zitadel/policy.proto
---
> This document reflects the state from API 1.0 (available from 20.04.2021)
## Enums
### MultiFactorType {#multifactortype}
| Name | Number | Description |
| ---- | ------ | ----------- |
| MULTI_FACTOR_TYPE_UNSPECIFIED | 0 | - |
| MULTI_FACTOR_TYPE_U2F_WITH_VERIFICATION | 1 | TODO: what does livio think after the weekend? :D |
### PasswordlessType {#passwordlesstype}
| Name | Number | Description |
| ---- | ------ | ----------- |
| PASSWORDLESS_TYPE_NOT_ALLOWED | 0 | - |
| PASSWORDLESS_TYPE_ALLOWED | 1 | PLANNED: PASSWORDLESS_TYPE_WITH_CERT |
### SecondFactorType {#secondfactortype}
| Name | Number | Description |
| ---- | ------ | ----------- |
| SECOND_FACTOR_TYPE_UNSPECIFIED | 0 | - |
| SECOND_FACTOR_TYPE_OTP | 1 | - |
| SECOND_FACTOR_TYPE_U2F | 2 | - |

37
docs/docs/apis/proto/project.md Normal file
View File

@@ -0,0 +1,37 @@
---
title: zitadel/project.proto
---
> This document reflects the state from API 1.0 (available from 20.04.2021)
## Enums
### ProjectGrantState {#projectgrantstate}
| Name | Number | Description |
| ---- | ------ | ----------- |
| PROJECT_GRANT_STATE_UNSPECIFIED | 0 | - |
| PROJECT_GRANT_STATE_ACTIVE | 1 | - |
| PROJECT_GRANT_STATE_INACTIVE | 2 | - |
### ProjectState {#projectstate}
| Name | Number | Description |
| ---- | ------ | ----------- |
| PROJECT_STATE_UNSPECIFIED | 0 | - |
| PROJECT_STATE_ACTIVE | 1 | - |
| PROJECT_STATE_INACTIVE | 2 | - |

109
docs/docs/apis/proto/user.md Normal file
View File

@@ -0,0 +1,109 @@
---
title: zitadel/user.proto
---
> This document reflects the state from API 1.0 (available from 20.04.2021)
## Enums
### AuthFactorState {#authfactorstate}
| Name | Number | Description |
| ---- | ------ | ----------- |
| AUTH_FACTOR_STATE_UNSPECIFIED | 0 | - |
| AUTH_FACTOR_STATE_NOT_READY | 1 | - |
| AUTH_FACTOR_STATE_READY | 2 | - |
| AUTH_FACTOR_STATE_REMOVED | 3 | - |
### Gender {#gender}
| Name | Number | Description |
| ---- | ------ | ----------- |
| GENDER_UNSPECIFIED | 0 | - |
| GENDER_FEMALE | 1 | - |
| GENDER_MALE | 2 | - |
| GENDER_DIVERSE | 3 | - |
### SessionState {#sessionstate}
| Name | Number | Description |
| ---- | ------ | ----------- |
| SESSION_STATE_UNSPECIFIED | 0 | - |
| SESSION_STATE_ACTIVE | 1 | - |
| SESSION_STATE_TERMINATED | 2 | - |
### Type {#type}
| Name | Number | Description |
| ---- | ------ | ----------- |
| TYPE_UNSPECIFIED | 0 | - |
| TYPE_HUMAN | 1 | - |
| TYPE_MACHINE | 2 | - |
### UserFieldName {#userfieldname}
| Name | Number | Description |
| ---- | ------ | ----------- |
| USER_FIELD_NAME_UNSPECIFIED | 0 | - |
| USER_FIELD_NAME_USER_NAME | 1 | - |
| USER_FIELD_NAME_FIRST_NAME | 2 | - |
| USER_FIELD_NAME_LAST_NAME | 3 | - |
| USER_FIELD_NAME_NICK_NAME | 4 | - |
| USER_FIELD_NAME_DISPLAY_NAME | 5 | - |
| USER_FIELD_NAME_EMAIL | 6 | - |
| USER_FIELD_NAME_STATE | 7 | - |
| USER_FIELD_NAME_TYPE | 8 | - |
### UserGrantState {#usergrantstate}
| Name | Number | Description |
| ---- | ------ | ----------- |
| USER_GRANT_STATE_UNSPECIFIED | 0 | - |
| USER_GRANT_STATE_ACTIVE | 1 | - |
| USER_GRANT_STATE_INACTIVE | 2 | - |
### UserState {#userstate}
| Name | Number | Description |
| ---- | ------ | ----------- |
| USER_STATE_UNSPECIFIED | 0 | - |
| USER_STATE_ACTIVE | 1 | - |
| USER_STATE_INACTIVE | 2 | - |
| USER_STATE_DELETED | 3 | - |
| USER_STATE_LOCKED | 4 | - |
| USER_STATE_SUSPEND | 5 | - |
| USER_STATE_INITIAL | 6 | - |

14
docs/docs/concepts/architecture.md
View File

@@ -2,7 +2,7 @@
title: ZITADEL Architecture
---
### Software Architecture
## Software Architecture
**ZITADEL** is built with two essential patterns. Eventsourcing and CQRS. Due to the nature of eventsourcing **ZITADEL** provides the unique capability to generate a strong audit trail of ALL the things that happen to its resources, without compromising on storage cost or audit trail length.
@@ -12,7 +12,7 @@ Each **ZITADEL** contains all components of the IAM, from serving as API, render
![Software Architecture](/img/zitadel_software_architecture.png)
#### Component Command Side
### Component Command Side
The **command handler** receives all operations who alter a IAM resource. For example if a user changes his name.
This information is then passed to **command validation** for processing of the business logic, for example to make sure that the user actually can change his name. If this succeeds all generated events are inserted into the eventstore when required all within one transaction.
@@ -22,7 +22,7 @@ This information is then passed to **command validation** for processing of the
> When we classify this with the CAP theorem we would choose **Consistent** and **Available** but leave **Performance** aside.
#### Component Spooler
### Component Spooler
The spoolers job is it to keep a query view up-to-date or at least look that it does not have a too big lag behind the eventstore.
Each query view has its own spooler who is responsible to look for the events who are relevant to generate the query view. It does this by triggering the relevant projection.
@@ -31,7 +31,7 @@ Spoolers are especially necessary where someone can query datasets instead of si
> The query side has the option to dynamically check the eventstore for newer events on a certain id, see query side for more information
> Each view can have exactly one spooler, but spoolers are dynamically leader elected, so even if a spooler crashes it will be replaced in a short amount of time.
#### Component Query Side
### Component Query Side
The query handler receives all read relevant operations. These can either be query or simple `getById` calls.
When receiving a query it will proceed by passing this to the repository which will call the database and return the dataset.
@@ -44,11 +44,11 @@ If a request calls for a specific id the call will, most of the times, be revali
> When we classify this with the CAP theorem we would choose **Available** and **Performance** but leave **Consistent** aside
> TODO explain more here
#### Component HTTP Server
### Component HTTP Server
The http server is responsible for serving the management GUI called **ZITADEL Console**, serving the static assets and as well rendering server side html (login, password-reset, verification, ...)
### Cluster Architecture
## Cluster Architecture
A **ZITADEL Cluster** is a highly available IAM system with each component critical for serving traffic laid out at least three times.
As our storage (CockroachDB) relies on Raft it is also necessary to always utilizes odd numbers to address for "split brain" scenarios.
@@ -60,7 +60,7 @@ If you deploy **ZITADEL** with our GITOPS Tooling [**ORBOS**](https://github.com
![Cluster Architecture](/img/zitadel_cluster_architecture.png)
### Multi Cluster Architecture
## Multi Cluster Architecture
To scale **ZITADEL** is recommend to create smaller clusters, see cluster architecture and then create a fabric which interconnects the database.
In our reference design we recommend to create a cluster per cloud provider or availability zone and to group them into regions.

2
docs/docs/concepts/principles.md
View File

@@ -2,7 +2,7 @@
title: Principles
---
### ZITADEL engineering and design principles
## ZITADEL engineering and design principles
- Be transparent about your decisions
- Embrace stateless application design

14
docs/docs/guides/identity-brokering.md
View File

@@ -28,7 +28,7 @@ title: Identity Brokering
</tr>
</table>
### What is Identity Brokering and Federated Identities?
## What is Identity Brokering and Federated Identities?
Federated identity management is an arrangement built upon the trust between two or more domains. Users of these domains are allowed to access applications and services using the same identity.
This identity is known as federated identity and the pattern behind this as identity federation.
@@ -43,11 +43,11 @@ Because Google is registered as trusted identity provider the user will be able
![Identity Brokering](/img/zitadel_identity_brokering.png)
### Exercise: Register an external identity provider
## Exercise: Register an external identity provider
In this exercise we will add a new Google identity provider to federate identities with ZITADEL.
#### 1. Create new OIDC Client
### 1. Create new OIDC Client
1. Register an OIDC Client in your preferred provider
2. Make sure you add the ZITADEL callback redirect uris
@@ -66,7 +66,7 @@ Google Example:
![Add new oAuth credentials in Google Console](/img/google_add_credentials.gif)
#### 2. Add custom login policy on your organisation
### 2. Add custom login policy on your organisation
1. Go to your organisation settings by clicking on "Organisation" in the menu or using the following link: <https://console.zitadel.ch/org>
2. Modify your login policy
@@ -74,7 +74,7 @@ Google Example:
![Add custom login policy](/img/console_org_custom_login_policy.gif)
#### 3.Configure new identity provider
### 3.Configure new identity provider
1. Go to the identity providers section and click new
2. Fill out the form
@@ -89,7 +89,7 @@ Google Example:
Your user will now be able to choose Google for login instead of username/password or mfa.
### Knowledge Check
## Knowledge Check
* The issuer for your identity provider is <https://issuer.zitadel.ch>
- [ ] yes
@@ -112,7 +112,7 @@ Your user will now be able to choose Google for login instead of username/passwo
</details>
### Summary
## Summary
* You can federate identities of all oAuth 2.0 compliant external identity providers
* Configure the provider in your custom login policy

12
docs/docs/guides/oauth-recommended-flows.md
View File

@@ -8,7 +8,7 @@ title: Recommended authorization flows
| Learning Outcomes | In this module you will: <ul><li>Learn the basics of federated identities</li><li>Understand the basics of OAuth 2.x client profiles and their importance for authorization flows</li><li>Get a recommended flow for Web, Native, User-Agent, and API</li></ul> |
| Prerequisites | Basic knowledge about federated identities. |
### Introduction
## Introduction
Before we get into setting up our first application within ZITADEL, we need to go through some basics on how to obtain an authorization with OpenID Connect 1.x and OAuth 2.x.
@@ -18,7 +18,7 @@ We invite you to further explore the different authorization flows in the OAuth
So this module will only go over the basics and explain why we recommend the flow “Authorization Flow with PKCE” as default for most applications. We will also cover the case of machine-to-machine communication, ie. where there is no interactive login. Further we will guide you to further reading viable alternatives, if the default flow is not feasible.
### Basics of Federated Identity
## Basics of Federated Identity
Although Federated Identities are not a new concept ([RFC 6749](https://tools.ietf.org/html/rfc6749), “The OAuth 2.0 Authorization Framework” was released in 2012) it is important to highlight the difference between the traditional client-server authentication model and the concept of delegated authorization and authentication.
@@ -46,7 +46,7 @@ This is where the so-called “flows” come into play: There are a number of di
Maybe interesting to mention is that we are mostly concerned with choosing the right OAuth 2.x flows (alas “authorization”). OpenID Connect extends the OAuth 2.x flow with useful features like endpoint discovery (where to ask), ID Token (who is the user, when and how did she authenticate), and UserInfo Endpoint (getting additional information about the user).
### Different client profiles
## Different client profiles
As mentioned in the beginning of this module, there are two main determinants for choosing the optimal authorization flow:
@@ -86,7 +86,7 @@ The following table gives you a brief overview of different client profiles.
</tr>
</table>
### Our recommended authorization flows
## Our recommended authorization flows
We recommend using the flow **“Authorization Code with Proof Key of Code Exchange (PKCE)”** ([RFC7636](https://tools.ietf.org/html/rfc7636)) for **User-Agent**, **Native**, and **Web** clients.
@@ -104,7 +104,7 @@ A JWT with a private key can also be used with client profile web to further enh
In case you need alternative flows and their advantages and drawbacks, there will be a module to outline more methods and our recommended fallback strategy per client profile that are available in ZITADEL.
### Knowledge Check (3)
## Knowledge Check (3)
* With federated identities the user sends credentials to the server holding the protected resource
- [ ] yes
@@ -133,7 +133,7 @@ In case you need alternative flows and their advantages and drawbacks, there wil
</details>
### Summary (3)
## Summary (3)
* Federated Identities solve key problems and challenges with traditional server-client architecture
* Use “Authorization Code with Proof Key of Code Exchange (PKCE)” for User-Agent, Native, and Web clients

24
docs/sidebars.js
View File

@@ -31,9 +31,27 @@ module.exports = {
apis: [
'apis/introduction',
'apis/domains',
'apis/authn',
'apis/admin',
'apis/mgmt',
'apis/apis',
{
type: 'category',
label: 'Proto API Definition',
items: [
'apis/proto/auth',
'apis/proto/management',
'apis/proto/admin',
'apis/proto/org',
'apis/proto/user',
'apis/proto/app',
'apis/proto/policy',
'apis/proto/auth_n_key',
'apis/proto/change',
'apis/proto/idp',
'apis/proto/member',
'apis/proto/message',
'apis/proto/object',
'apis/proto/options',
],
},
{
type: 'category',
label: 'OpenID Connect & OAuth',