1. Login service authenticate users with username and password and give back an OGCX auth signed token. Login service can be used by any third party application for user authentication in the OG.CX scope. Token is signed with OGCX private key and can be validated by third parties using OGCX public key, so there is no need to query the login service to validate a token but it can be done in the third party application itself.
2. The flow would be like this:
3. 1. User logs in against token provider (login.og.cx)
4. 2. Token provider creates a token that contains at least an expiry date/time and a shared unique user id, the back-end service knows this token.
5. 3. Token provider signs the token, for example with a deterministically seeded key (EC can work and that's relatively cheap)
6. 4. User is redirected to token consumer and replays the token in the http header (app.og.cx)
7. 5. Token consumer parses the token, splits off the sig
8. 6. Token consumer validates the sig
9. 7. Token consumer validates the expiry date
10. 8. Token consumer gives access to the user if all the validation succeeded
11. For this to work we need a deterministic key generation process on all services (only pubkey segment on the token consumers) somewhat like how it's used in Bitcoin protocol 32: https://raw.githubusercontent.com/bitcoin/bips/master/bip-0032/derivation.png
12. In the token are stored at least:
13. User e-mail
14. User role
15. User ID
16. The service that receives an user token can query the login service if he needs more information about the user.