Overview#Grant Negotiation and Authorization Protocol (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.
This protocol allows a piece of software, the client instance, to request delegated authorization to Resource Servers and to request direct information. This delegation is facilitated by an Authorization Server usually on behalf of a Resource Owner. The end-user operating the software may interact with the Authorization Server to authenticate, provide consent, and authorize the request.
This protocol solves many of the same use cases as OAuth 2.0 RFC 6749, OpenID Connect (OIDC), and the family of protocols that have grown up around that ecosystem. However, GNAP is not an extension of OAuth 2.0 and is not intended to be directly compatible with OAuth 2.0. GNAP seeks to provide functionality and solve use cases that OAuth 2.0 cannot easily or cleanly address. Even so, GNAP and OAuth 2.0 will exist in parallel for many deployments, and considerations have been taken to facilitate the mapping and transition from legacy systems to GNAP. Some examples of these can be found in Appendix C.5.
1.2. Roles#The parties in GNAP perform actions under different roles. Roles are defined by the actions taken and the expectations leveraged on the role by the overall protocol.
Client#Application operated by an end-user that consumes resources from one or several Resource Servers, possibly requiring access privileges from one or several Authorization Servers.
Example: a client can be a mobile application, a web application, etc.
Note: this specification differentiates between a specific instance (the client instance, identified by its unique key) and the software running the instance (the client software). For some kinds of client software, there could be many instances of that software, each instance with a different key.
Resource Server (RS)#A server that provides operations on Protected Resources, where operations require a valid Access_token issued by an Authorization Server.
Resource Owner (RO)#Is a subject entity that may grant or deny operations on resources it has authority upon.
Note: the act of granting or denying an operation may be manual (i.e. through an interaction with a physical person) or automatic (i.e. through predefined organizational rules).
End-user#A Natural Person that operates a client instance. (Remember a "Client Instance" is an Application)
1.3. Elements#In addition to the roles above, the protocol also involves several elements that are acted upon by the roles throughout the process. subject. data artifact representing a set of rights and/or attributes.
Note: the Resource Owner defines and maintains the rights and attributes associated to the protected resource, and might temporarily delegate some set of those privileges to an end-user. This process is referred to as privilege delegation.API (Application Programming Interface) served by an Resource Server and that can be accessed by a client, if and only if a valid Access Token is provided.
Note: to avoid complex sentences, the specification document may simply refer to resource instead of protected resource.subject to perform a given operation on a resource under the control of an Resource Server.