Authorization Server: Difference between revisions
Jump to navigation
Jump to search
| Line 14: | Line 14: | ||
===Healthcare=== | ===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 fro* [https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html#rs-rpt-response User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization] provides consent to the [[Authorization Server]] in order to capture [[Patient Consent]]. | See the wiki page [[Patient Consent]] for details on getting permission to issue a token for health recous. The following flows follows the pattern fro* [https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html#rs-rpt-response User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization] provides consent to the [[Authorization Server]] in order to capture [[Patient Consent]]. | ||
# Client Requests Resource Without Providing an Access Token | # Client Requests Resource Without Providing an Access Token - the proposed solution is for the [[Resource Server]] to verify that the client is a HIPAA covered entity in the quickest possible manner. | ||
# | # esource Server Responds to Client's Tokenless Access Attempt | ||
# | #Client Seeks RPT on Requesting Party's Behalf | ||
# | #Authorization Assessment and Results Determination | ||
# | # | ||
Revision as of 01:18, 17 April 2020
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 fro* User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization provides consent to the Authorization Server in order to capture Patient Consent.
- Client Requests Resource Without Providing an Access Token - the proposed solution is for the Resource Server to verify that the client is a HIPAA covered entity in the quickest possible manner.
- esource Server Responds to Client's Tokenless Access Attempt
- Client Seeks RPT on Requesting Party's Behalf
- Authorization Assessment and Results Determination
References
- D. Hardt, The OAuth 2.0 Authorization Framework IEtF 6749 https://www.rfc-editor.org/rfc/pdfrfc/rfc6749.txt.pdf