diff --git a/docs/login-flow.md b/docs/login-flow.md
index 2175206f0a..ab450d9015 100644
--- a/docs/login-flow.md
+++ b/docs/login-flow.md
@@ -10,7 +10,7 @@ geekdocFilePath: login-flow.md
## Login Flow
-The following sequence diagram describes the [openid connect auth flow](https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth):
+The following sequence diagram describes the [openid connect auth code flow](https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth). The eight numbered steps and notes correspond to the [openid connect auth code flow steps](https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowSteps). Example requests are based on the spec as well.:
{{< mermaid class="text-center">}}
sequenceDiagram
@@ -21,8 +21,7 @@ sequenceDiagram
participant user as User
participant client as Client
participant proxy as ocis-proxy
- participant idp as external IdP
- participant konnectd as ocis-konnectd IdP
+ participant idp as IdP
participant glauth as ocis-glauth
participant graph as ocis-graph
participant accounts as ocis-accounts
@@ -31,26 +30,33 @@ sequenceDiagram
user->>+client: What is the content of my home?
client->>+proxy: PROPFIND
no (or expired) auth
- alt proxy can decide which idp to use
- Note over client, idp: We may not be able to differentiate guests from users
- proxy-->>client: 302 Found
- Note over client, idp: HTTP/1.1 302 Found
Location: https://server.example.com/authorize?
response_type=code&
scope=openid%20profile%20email
&client_id=s6BhdRkqt3
&state=af0ifjsldkj
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
- else client needs to discover the idp
- proxy-->>-client: 401 Unauthorized
- Note over client, idp: Follow OpenID Connect Discovery protocol
- Note over client, idp: Clients might fall back to the ocis server if the discovery failed.
We can provide a webfinger endpoint there to let guests use an idp
that is backed bythe accounts service.
- Note over client, idp: For now, always use ocis well known endpoint to discover idp?
We can check the email in the accounts service.
- end
+ Note over client,proxy: ocis needs to know the IdP that is
used to authenticate users. The
proxy will redirect unauthenticated
requests to that IdP.
+ proxy-->>-client: 302 Found
+ Note over client, idp: HTTP/1.1 302 Found
Location: https://server.example.com/authorize?
response_type=code&
scope=openid%20profile%20email
&client_id=s6BhdRkqt3
&state=af0ifjsldkj
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
+
+ Note over client, idp: We should follow the OpenID Connect Discovery protocol
+ Note over client, idp: Clients might fall back to the ocis server if the discovery failed.
We can provide a webfinger endpoint there to let guests use an idp
that is backed by the accounts service.
+ Note over client, idp: For now, clients can only handle one IdP, which is configured in ocis.
client-->>client: 1. Client prepares an Authentication Request
containing the desired request parameters.
- alt all users authenticated by an external idp
- client->>+idp: 2. Client sends the request to the Authorization Server.
- Note over client, idp: GET /authorize?
response_type=code
&scope=openid%20profile%20email
&client_id=s6BhdRkqt3
&state=af0ifjsldkj
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1
Host: server.example.com
- Note over user, idp: 3. Authorization Server Authenticates the End-User.
+ client->>+idp: 2. Client sends the request to the Authorization Server.
+ Note over client, idp: GET /authorize?
response_type=code
&scope=openid%20profile%20email
&client_id=s6BhdRkqt3
&state=af0ifjsldkj
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1
Host: server.example.com
+ Note over user, idp: 3. Authorization Server Authenticates the End-User.
+ Note over idp,ldap: Either an IdP already exists or a new one is introduced. Since we are not yet using oidc discovery we can only use one IdP.
+ alt all users managed by konnectd/ocis
+ idp->>+glauth: LDAP query/bind
+ glauth->>+graph: GET user with Basic Auth
GraphAPI
+ graph->>+accounts: internal GRPC
+ accounts-->>-graph: response
+ graph-->>-glauth: OData response
+ glauth-->>-idp: LDAP result
+ Note over accounts,ldap: In case internal users are managed
in an external ldap they have to be
synced to the accounts service to
show up as recipients during sharing.
+ else all users authenticated by an external idp
idp->>+ldap: LDAP query/bind
ldap-->>-idp: LDAP result
alt guest accounts managed in ocis / lookup using glauth proxy:
+ Note over idp,glauth: Idp is configured to use glauth as a
second ldap server.
idp->>+glauth: LDAP query/bind
glauth->>+graph: GET user with Basic Auth
GraphAPI
graph->>+accounts: internal GRPC
@@ -58,38 +64,18 @@ sequenceDiagram
graph-->>-glauth: OData response
glauth-->>-idp: LDAP result
else guest account provisioned by other means
- Note over idp, ldap: In case guest accounts are stored in an existing ldap they need to be synced to the accounts service to show up as recipients during sharing.
+ Note over accounts, ldap: In case guest accounts are managed
in an existing ldap they need to be
synced to the accounts service to
be able to login and show up as
recipients during sharing.
end
-
- Note over user, idp: 4. Authorization Server obtains End-User Consent/Authorization.
- idp-->>-client: 5. Authorization Server sends the End-User back
to the Client with an Authorization Code.
- Note over client, idp: HTTP/1.1 302 Found
Location: https://client.example.org/cb?
code=SplxlOBeZQQYbYS6WxSbIA&state=af0ifjsldkj
-
- client->>+idp: 6. Client requests a response using the
Authorization Code at the Token Endpoint.
- Note over client, idp: POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
- idp-->>-client: 7. Client receives a response that contains an
ID Token and Access Token in the response body.
- Note over client, idp: HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"access_token": "SlAV32hkKG",
"token_type": "Bearer",
"refresh_token": "8xLOxBtZp8",
"expires_in": 3600,
"id_token": "a ... b.c ... d.e ... f" // must be a JWT
}
- else all users managed by konnectd/ocis
- client->>+konnectd: 2. Client sends the request to the Authorization Server.
- Note over client, konnectd: GET /authorize?
response_type=code
&scope=openid%20profile%20email
&client_id=s6BhdRkqt3
&state=af0ifjsldkj
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1
Host: server.example.com
- Note over user, konnectd: 3. Authorization Server Authenticates the End-User.
- konnectd->>+glauth: LDAP query/bind
- glauth->>+graph: GET user with Basic Auth
GraphAPI
- graph->>+accounts: internal GRPC
- accounts-->>-graph: response
- graph-->>-glauth: OData response
- glauth-->>-konnectd: LDAP result
- Note over konnectd,ldap: In case the internal users come from an external ldap they have to be synced to the accounts service to show up as recipients during sharing.
-
- Note over user, konnectd: 4. Authorization Server obtains End-User Consent/Authorization.
- konnectd-->>-client: 5. Authorization Server sends the End-User back
to the Client with an Authorization Code.
- Note over client, konnectd: HTTP/1.1 302 Found
Location: https://client.example.org/cb?
code=SplxlOBeZQQYbYS6WxSbIA&state=af0ifjsldkj
-
- client->>+konnectd: 6. Client requests a response using the
Authorization Code at the Token Endpoint.
- Note over client, konnectd: POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
- konnectd-->>-client: 7. Client receives a response that contains an
ID Token and Access Token in the response body.
- Note over client, konnectd: HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"access_token": "SlAV32hkKG",
"token_type": "Bearer",
"refresh_token": "8xLOxBtZp8",
"expires_in": 3600,
"id_token": "a ... b.c ... d.e ... f" // must be a JWT
}
end
+ Note over user, idp: 4. Authorization Server obtains End-User Consent/Authorization.
+ idp-->>-client: 5. Authorization Server sends the End-User back
to the Client with an Authorization Code.
+ Note over client, idp: HTTP/1.1 302 Found
Location: https://client.example.org/cb?
code=SplxlOBeZQQYbYS6WxSbIA&state=af0ifjsldkj
+
+ client->>+idp: 6. Client requests a response using the
Authorization Code at the Token Endpoint.
+ Note over client, idp: POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
+ idp-->>-client: 7. Client receives a response that contains an
ID Token and Access Token in the response body.
+ Note over client, idp: HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"access_token": "SlAV32hkKG",
"token_type": "Bearer",
"refresh_token": "8xLOxBtZp8",
"expires_in": 3600,
"id_token": "a ... b.c ... d.e ... f" // must be a JWT
}
+
client-->>client: 8. Client validates the ID token and
retrieves the End-User's Subject Identifier.