Overview#
OAuth 2.0 Use case SummaryUse Case | Trustworthiness | Suggested OAuth 2.0 Authorization Grant_type | Description |
---|---|---|---|
B2B (extranet), intranet, other | Highly trusted Applications, written by internal developer or developers with a trusted business relationship with the API Provider. Applications that need to access resources on their own behalf. | Client Credentials Grant | Typically, the Application is also the Resource Owner Requires Client_id and Client Secret keys Requires OAuth 2.0 Client Registration |
Intranet sites, portals | Trusted Applications written by internal or trusted third-party developers. A good example is logging in to your company HR site to make insurance selections, submit reviews, or change personal information. | Resource Owner Password Credentials Grant | Requires Client_id and Client Secret, plus UserId and password Requires OAuth 2.0 Client Registration |
Publicly available Applications | Untrusted Applications written by third-party developers who do not have a trusted business relationship with the API Provider. For example, developers who register for public API programs should not generally be trusted. | Authorization Code Grant | Requires user to log in to Authorization Server Applications never sees UserId and password Requires OAuth 2.0 Client Registration |
B2C | There is an individual end user (mobile user) involved, and user credentials are stored on the mobile Device. | Implicit Grant | User credentials are stored on the device running the Application. Requires OAuth 2.0 Client Registration |
More Information#
There might be more information for this subject on one of the following:- [#1] - Summary of OAuth 2.0 use cases
- based on information obtained 2017-02-20-