mirror/opencloud
1
0
Fork 0
mirror of https://github.com/opencloud-eu/opencloud.git synced 2026-01-03 19:00:05 -06:00
Code Issues Packages Projects Releases Wiki Activity

Simplify login-flow and add PKCE

Browse Source
This commit is contained in:
Michael Barz
2024-03-06 21:02:14 +01:00
committed by GitHub
parent be2e769def
commit d371c998dd
1 changed files with 23 additions and 48 deletions
Download Patch File Download Diff File Expand all files Collapse all files

71
docs/ocis/flow-docs/login-flow.md
View File

@@ -22,63 +22,38 @@ sequenceDiagram
participant client as Client
participant proxy as ocis-proxy
participant idp as IdP
participant glauth as ocis-glauth
participant graph as ocis-graph
participant accounts as ocis-accounts
participant ldap as external LDAP server
participant idm as LibreIDM
participant ldap as External User Directory
user->>+client: What is the content of my home?
client->>+proxy: PROPFIND <br> no (or expired) auth
Note over client,proxy: ocis needs to know the IdP that is<br>used to authenticate users. The<br>proxy will redirect unauthenticated<br>requests to that IdP.
proxy-->>-client: 302 Found
Note over client, idp: HTTP/1.1 302 Found<br>Location: https://server.example.com/authorize?<br>response_type=code&<br>scope=openid%20profile%20email<br>&client_id=s6BhdRkqt3<br>&state=af0ifjsldkj<br>&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.<br>We can provide a webfinger endpoint there to let guests use an idp<br>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<br>containing the desired request parameters.
client->>+idp: 2. Client sends the request to the Authorization Server.
Note over client, idp: GET /authorize?<br>response_type=code<br>&scope=openid%20profile%20email<br>&client_id=s6BhdRkqt3<br>&state=af0ifjsldkj<br>&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1<br>Host: server.example.com
proxy-->>-client: 401 Unauthorized
client->>+proxy: 1. The client starts a new openIDConnect Flow
Note over client, proxy: GET /.well-known/openid-configuration
proxy-->>-client: Return openidConnect configuration for the IdP
client-->>client: 2. Client prepares an Authentication Request<br>containing the desired request parameters <br> and generates the code challenge (PKCE).
client->>+idp: 3. Client sends the request and the code challenge to the Authorization Server.
Note over client, idp: GET /authorize?<br>flow=oidc&response_type=code<br>&scope=openid%20profile%20email<br>&code_challenge=Y2SGoq9vtAp7YAavTaO0B550H_Rsj9DypiL7xZuFjOE<br>&code_challenge_method=S25&client_id=s6BhdRkqt3<br>&state=af0ifjsldkj<br>&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1<br>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 idp/ocis
idp->>+glauth: LDAP query/bind
glauth->>+graph: GET user with Basic Auth<br>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<br>in an external ldap they have to be<br>synced to the accounts service to<br>show up as recipients during sharing.
alt all users managed by idp/ocis idm
idp->>+idm: LDAP query/bind
idm-->>-idp: LDAP result
Note over idp,ldap: In case users are managed<br>in an external ldap they have to be<br> autoprovisioned in the ocis IdM<br> when they are loggin in.
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<br>second ldap server.
idp->>+glauth: LDAP query/bind
glauth->>+graph: GET user with Basic Auth<br>GraphAPI
graph->>+accounts: internal GRPC
accounts-->>-graph: response
graph-->>-glauth: OData response
glauth-->>-idp: LDAP result
else guest account provisioned by other means
Note over accounts, ldap: In case guest accounts are managed<br>in an existing ldap they need to be<br>synced to the accounts service to<br>be able to login and show up as<br>recipients during sharing.
end
idp->>+ldap: Lookup of the user in the directory
ldap-->>-idp: Lookup result
end
Note over user, idp: 4. Authorization Server obtains End-User Consent/Authorization.
idp-->>-client: 5. Authorization Server sends the End-User back<br>to the Client with an Authorization Code.
idp-->>-user: Idp presents the user an authentication prompt.
user->>+idp: 5. User authenticates and gives consent.
idp-->>-client: 6. Authorization Server sends the End-User back<br>to the Client with an Authorization Code.
Note over client, idp: HTTP/1.1 302 Found<br>Location: https://client.example.org/cb?<br>code=SplxlOBeZQQYbYS6WxSbIA&state=af0ifjsldkj
client->>+idp: 6. Client requests a response using the<br>Authorization Code at the Token Endpoint.
Note over client, idp: POST /token HTTP/1.1<br>Host: server.example.com<br>Content-Type: application/x-www-form-urlencoded<br>grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA<br>&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
idp-->>-client: 7. Client receives a response that contains an<br>ID Token and Access Token in the response body.
client->>+idp: 7. Client requests a response using the<br>Authorization Code and the code verifier at the Token Endpoint.
Note over client, idp: POST /token HTTP/1.1<br>Host: server.example.com<br>Content-Type: application/x-www-form-urlencoded<br>grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA<br>&redirect_uri=https%3A%2F%2Fclient.example.org<br>&code_verifier=a98ccbe253754259963e6e2b67b5a044929446d7a15046cc8e3194022ad061d9d667dce91876418d9e6fe9f54819332e
idp->>+idp: 8. IdP checks the code verifier (PKCE)
idp-->>-client: 9. Client receives a response that contains an<br>ID Token and Access Token in the response body. <br>If offline access is requested, the client also receives a refresh token.
Note over client, idp: HTTP/1.1 200 OK<br>Content-Type: application/json<br>Cache-Control: no-store<br>Pragma: no-cache<br>{<br>"access_token": "SlAV32hkKG",<br>"token_type": "Bearer",<br>"refresh_token": "8xLOxBtZp8",<br>"expires_in": 3600,<br>"id_token": "a ... b.c ... d.e ... f" // must be a JWT<br>}
client-->>client: 8. Client validates the ID token and<br>retrieves the End-User's Subject Identifier.
client-->>client: 10. Client validates the ID token and<br>retrieves the End-User's Subject Identifier.
client->>+proxy: PROPFIND <br> With access token
proxy-->>-client: 207 Multi-Status
client-->>-user: List of Files X, Y, Z ...