Authorization Server

Full Title

Access tokens are issued to third-party clients by an Authorization Server with the approval of the resource owner. The client uses the access token to access the protected resources hosted by the resource server. Taken from RFC 6749

Context

• The ultimate purpose of most user authentication is to allow the user, or the user's client, to access protected resources. The abstract concept of an Authorization Server is just the source of the tokens that are sent to the Resource Server to give it the authority it needs to provide access to the protected asset.
• For the purposes of Identity Management this wiki will focus on the use of the Authorization Server.

Problems

• There are a wide range of attacks on the web to try to illegitimately acquire access to protected resources. Nearly of the complexity associated with an Authorization Server to to mitigate those threats.

Solutions

Specific virtual solutions:

Healthcare

See the wiki page Patient Consent for details on getting permission to issue a token for health recous. The following flows follows the pattern from User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization provides consent to the Authorization Server in order to capture Patient Consent. The the context of healthcare, a requesting party could be, for example, a physician in a large ehr making a request for patient data via that ehr.

1. Client Requests Resource Without Providing an Access Token with a list of requested access indicating which requests are essential - the proposed solution is for the Resource Server to verify that the client is a HIPAA covered entity in the quickest possible manner. The client MUST know the patient's record location code at the resource server.
2. Resource Server Responds to Client's Tokenless Access Attempt - with a list of its capability to respond to the to client's requests in a manner that the user can comprehend and that it can fulfill. The URL of the Authorization Server must be included.
3. Client generates a requesting party token (RPT) that gives the patient all of the information needed to make choice to consent, such as provider, purpose, etc.
4. Client Requests Resource with the requesting party token (RPT) - this request is bound to the client by a JWS signed token
5. Authorization Server Response to Client on Authorization Failure - and issues a token bound to the resource server and itself - this is NOT a bearer toekn
6. Authorization Server Refreshes the grants if requested using the same requesting party token (RPT)

References

• D. Hardt, The OAuth 2.0 Authorization Framework IEtF 6749 https://www.rfc-editor.org/rfc/pdfrfc/rfc6749.txt.pdf