One of the key aspects of GNAP is the addition of the user's identity information to the core protocol.
While OAuth was never intended to communicate information about the user who logged in to the app, many OAuth APIs added an endpoint that returns profile information about the user when requested with the access token.
GNAP aims to standardize this process.
GNAP also introduces the concept of "actors", which are entities that can act on behalf of other entities in the system.
Actors can be used to represent users, devices, or other entities that need to interact with the system.
The GNAP protocol will be used for authorization, API access, user identifiers, and identity assertions.
How GNAP Works
GNAP defines a mechanism for delegating authorization to a piece of software, and conveying that delegation to the software.
This delegation can include access to a set of APIs as well as information passed directly to the software.
Here's a simplified explanation of how GNAP works:
- Client Instance: The client instance is the software that is acting on behalf of the end user. It could be a browser, a native app, a server-side app, or any other piece of software.
- Requesting Party: The requesting party is the entity that is requesting access. This could be the end user, or it could be another piece of software acting on behalf of the end user.
- Authorization Server: The authorization server is the entity that understands the user's access policies and can issue tokens. This is similar to the role of the authorization server in OAuth 2.0.
- Resource Server: The resource server hosts the APIs or resources that the client instance wants to access.
The GNAP flow starts when the client instance makes a request to the authorization server.
This request includes what it's asking for, why it's asking for it, and how the end user can be involved in the decision.
The authorization server responds with a handle that the client instance can use to interact with the authorization server, as well as information about how the end user can be involved in the decision.
The client instance can then interact with the end user, if necessary, and then make a second request to the authorization server, using the handle that was provided in the first response.
The authorization server then responds with the access token that the client instance can use to access the resource server.
Endpoints
The GNAP protocol is designed to be easy to implement, with a simple message format and a small number of endpoints ยน. The endpoints used in GNAP include:
- /authorize: This endpoint is used to initiate the authorization process. It takes a set of parameters that describe the authorization request, and returns an authorization code or access token.
- /token: This endpoint is used to exchange an authorization code for an access token. It takes the authorization code as a parameter, along with other information such as the client ID and client secret, and returns an access token.
- /introspect: This endpoint is used to check the validity of an access token. It takes the access token as a parameter, and returns information about the token, such as its expiration time and the scopes it grants access to.
- /revoke: This endpoint is used to revoke an access token. It takes the access token as a parameter, and invalidates the token so that it can no longer be used to access protected resources.
These endpoints are similar to those used in OAuth 2.0, but they have been simplified and made more secure.
Comparison with OAuth 2.0
Based on the corresponding chapter of the standard GNAP differs from OAuth 2.0 in several ways:
- Consent and Authorization Flexibility: GNAP allows various patterns for managing authorizations and consents, including different ways to start and finish interactions, not limited to browsers. It supports information from client instances, external parties, and user interactions.
- Intent Registration and Inline Negotiation: Unlike OAuth 2.0's fixed grant types, GNAP requests start uniformly and negotiate subsequent steps based on client capabilities, access policies, and contextual information. It introduces a continuation API for exchanging additional information between the client and authorization server (AS) over multiple steps.
- Client Instances: OAuth 2.0 requires client registration at the AS and a known client_id. GNAP allows client instances to present an unknown key to the AS for ongoing request protection. It supports both pre-registered and dynamically registered clients without requiring a client_id in the protocol at all times.
- Expanded Delegation: GNAP introduces a rich structure for access requests, akin to OAuth 2.0's scope parameter. It defines methods for obtaining user information separate from API access and allows negotiation of token formats between the AS and resource server (RS).
- Cryptography-Based Security: While OAuth 2.0 relies on shared bearer secrets, GNAP binds all communication to a key held by the client instance. It uses cryptographic mechanisms for client authentication and access token binding, with the flexibility for extensions to define new protection mechanisms.
- Privacy and Usable Security: GNAP is designed for interoperability with decentralized identity standards, providing a human-centric authorization layer. It supports various communication patterns between RSs and ASs through extensions, aiming to avoid consolidation into a few popular AS services.
Conclusion
The development of GNAP represents a significant step forward in the field of authorization and authentication protocols.
By addressing the limitations of OAuth 2.0 and its extensions, GNAP promises to provide a more secure and unified solution for various use-cases.
As GNAP continues to evolve and mature, it is expected to play a crucial role in the security of authorization and authentication for the Web, IoT, and beyond.