I am trying to come up with (at this time) server-to-server distributed authorization/authentication that would have (near) the same advantages as OAuth2 but without it's drawbacks.
Is there any obvious issues to this flow that I am missing?
Please, comment if there is something to be clarified. Clearly not everything is spelled out here.
Consumer: application (server-side) that needs to authorize or authenticate the Subject
Subject: User who authorizes an application to access their account, identity and access level of whom needs to be verified.
Authority server: A server that can authenticate/authorize the Subject and provide Consumer with Subjects details
A_SID: Session identifier issued by Authority Server in response to Handshake Ticket, unique per Consumer.
A_URL: A URL that leads to Authority Server, generated by Authority server and contains A_SID as a parameter, OR contains any other value that Authority Server can relate to A_SID later in the flow;
A_EXP: A UTC timestamp indicating time after which A_SID should be considered invalid.
A_UID: globally-unique Subject identifier issued by Authority Server to each individual Subject.
C_ID: Consumer ID, issue to Authority Server beforehand (think - client ID).
C_SECRET: Consumer secret (think - client password).
C_URL: URL to which consumer will receive a callback when Authority server has finished processing Subject (think - callback URL) that contains A_SID as a parameter, OR contains any other value that Consumer can relate to A_SID later in the flow;
C_GRANT: List of one or more "roles" required by Consumer (think, verify whether or not Subject has access to X,Y roles).
C_SCOPE: List of one or more "pieces of information" of the Subject required by the Consumer (think access to users data).
Handshake Ticket: request that includes C_ID, C_SECRET and C_URL, sent from Consumer to the Authority Server to issue a new Redirect Ticket.
Redirect Ticket: response that includes A_EXP, A_SID and A_URL sent as response to Handshake Ticket from Authority Server to Consumer.
Result Request Ticket: request that includes C_ID, C_SECRET and A_SID sent to Authority Server by Consumer to request Result Ticket.
Result Ticket: Response to Consumer by Authority Server that contains state of the given session (error on failed auth, requested details on successful auth). For successful tickets contains A_UID, true/false for each C_GRANT, and true/false for each C_SCOPE, and A_EXP.
Refresh Ticket: A request sent to Authority Server by the Consumer that contains A_SID, C_ID and C_SECRET.
Refresh Result Ticket: A response sent to Consumer by Authority Server that contains the old A_SID, the new A_SID and A_EXP for the new A_SID. Errors out if the Refresh Ticket is sent after the old A_SID is expired.
Subject initiates the flow by indicating to the Consumer that the flow should begin (think - clicks on a "Login" button);
Consumer sends Handshake Ticket to the Authority Server;
Authority server verifies Consumers credentials, issues a Redirect Ticket to the Consumer and returns it as a response to the Handshake Ticket request;
Consumer reads and stores Redirect Ticket in a temporary storage (web session for example?);
Consumer redirects Subject to A_URL;
Authority Server authenticates/authorizes the Subject (successfully or not);
Authority Server redirects the Subject to C_URL;
Consumer sends Authority Server a Result Request ticket that includes C_ID, C_SECRET and A_SID;
Authority Server responds with Result Ticket.
Consumer sends Refresh Ticket to the Authority server before A_EXP for the current A_SID.
Authority server sends Refresh Result Ticket to the Consumer as a response to Refresh Ticket.
Pretty much calling an API from Authority Server with request that includes C_ID, C_SECRET, A_SID and A_UID.
- Clearly all communication happens over HTTPS/SSL.
- Messages over JWT (json web token)? Have not decided yet.
- Authority Server can impose numerous limitations on Consumer, for example, restrict C_URL, IP of the Consumer, limit what C_GRANT and what C_SCOPE etc can be requested etc. Again, not exactly spelled out yet.