3

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.

Parties:

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.

Notes:

  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.
Matiss
  • 133
  • 4
  • 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 02:46
  • @NeilSmithline which established protocol would you suggest? – Matiss Apr 11 '18 at 08: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
  • See [Why shouldn't we roll our own?](https://security.stackexchange.com/questions/18197/why-shouldnt-we-roll-our-own/). – Neil Smithline Apr 11 '18 at 13:24
  • @Limit yes, Kerberos is often good choice, yet, I am looking to expand on the basic flow described here to provide certain features that Kerberos is not able to support, no matter how much hax. – Matiss Apr 11 '18 at 13:58
  • @NeilSmithline see [Is reinventing the wheel really all that bad?](https://softwareengineering.stackexchange.com/a/29527/188739). – Matiss Apr 11 '18 at 14:03
  • FIrst, the top-voted answer to that question is much more conservative and recommends using context. Second, this is security, not general programming - it's different. Authentication and authorization standards are created over years by a group of experts with extensive public review and revisions. The implementations are then tested before being released and then tested for real once released. Without a similar process, you will never create something as strong as an existing, robust solution. How about you tell us what your concerns are with using existing standards and we'll try to help. – Neil Smithline Apr 11 '18 at 14:10
  • @NeilSmithline thank you for your insight - it is appreciated. That being said, your opinion on whether or not this is useful, should be implemented, or anything of the kind is not what is being asked for, nor what is being discussed here - the proposed flow is. If you have nothing more of value to add, or any questions that needs clarification, to which I would happily provide answers to, there surely are plenty of other questions on SXC you might actually have an answer to. – Matiss Apr 11 '18 at 14:30
  • I am not sure if this is part of the threat model for OAuth or your protocol. But, is the following scenario possible? Say you have a rogue consumer. You have a single authorized service among all so I am guessing you have the same username/password for all. Since the consumer can see your username and password in plaintext, can they use them to authenticate to benign consumers and do something? – Limit Apr 11 '18 at 15:31
  • @Limit Yes, I considered the OAuth limitations. Consumer will never be able to to see Subject's password, or login using user/password against the Authority. I was considering allowing that for "trusted consumers", but that is simply not necessary - I have some ideas on how to avoid that. The only way to log in to the service is by the user to login into the Authority Server directly. Username and password never leaves Authority server and the tokens issued are bound to consumers, so a token issued to one consumer can not be used by another consumer. – Matiss Apr 11 '18 at 15:52

0 Answers0