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).

Tickets (requests/responses):

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.

Initial flow:

  1. Subject initiates the flow by indicating to the Consumer that the flow should begin (think - clicks on a "Login" button);

  2. Consumer sends Handshake Ticket to the Authority Server;

  3. Authority server verifies Consumers credentials, issues a Redirect Ticket to the Consumer and returns it as a response to the Handshake Ticket request;

  4. Consumer reads and stores Redirect Ticket in a temporary storage (web session for example?);

  5. Consumer redirects Subject to A_URL;

  6. Authority Server authenticates/authorizes the Subject (successfully or not);

  7. Authority Server redirects the Subject to C_URL;

  8. Consumer sends Authority Server a Result Request ticket that includes C_ID, C_SECRET and A_SID;

  9. Authority Server responds with Result Ticket.

Refresh flow:

  1. Consumer sends Refresh Ticket to the Authority server before A_EXP for the current A_SID.

  2. Authority server sends Refresh Result Ticket to the Consumer as a response to Refresh Ticket.

Getting data:

Pretty much calling an API from Authority Server with request that includes C_ID, C_SECRET, A_SID and A_UID.


  1. Clearly all communication happens over HTTPS/SSL.
  2. Messages over JWT (json web token)? Have not decided yet.
  3. 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.
  • Are the tickets cleartext or encrypted? – A. Darwin Apr 10 '18 at 17:50
  • @A.Darwin I am leaning towards using JWT, so signed, but with explicitly forbidden none scheme and unsafe options. Also mandatory SSL for sure. – Matiss Apr 10 '18 at 17:52
  • What drawbacks are you concerned with? I really prefer going with an established protocol over a new one. – Neil Smithline Apr 11 '18 at 2:46
  • @NeilSmithline which established protocol would you suggest? – Matiss Apr 11 '18 at 8:56
  • Kerberos is an authentication/authorization protocol that people often use. Is there some drawback of that which made you not use it? – Limit Apr 11 '18 at 13:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.