Login Flow

Login Flow

The following sequence diagram describes the openid connect auth code flow. The eight numbered steps and notes correspond to the openid connect auth code flow steps. Example requests are based on the spec as well:

sequenceDiagram
    %% we have comments!! \o/
    %% this documents the login workflow
    %% examples taken from the oidc spec https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth
    %% TODO add PKCE, see https://developer.okta.com/blog/2019/08/22/okta-authjs-pkce#use-pkce-to-make-your-apps-more-secure
    participant user as User
    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

    user->>+client: What is the content of my home?

        client->>+proxy: PROPFIND 
no (or expired) auth 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. 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 idp/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 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
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 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. client->>+proxy: PROPFIND
With access token proxy-->>-client: 207 Multi-Status client-->>-user: List of Files X, Y, Z ...