Could this authentication/authorization flow be attacked without compromising the Authority Server?

Question

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.