←Behaviour - Resource Servers · Index↑ · Upgrade Path→
See also the NMOS Glossary for concepts regarding the JT-NM reference architecture, and definitions within RFCs.
The below definitions are based on the OAuth 2.0 spec.
An HTTP/WebSocket Application Programming Interface as defined in an AMWA NMOS Specification (e.g. IS-04, IS-05, IS-06, etc.)
Any part of the API that is access-restricted. This may apply to read (e.g GET) or write (e.g POST) operations.
The entity that is providing APIs containing protected resources, for example:
- a Registry implementing IS-04 Registration and Query APIs
- a Node implementing IS-04 Node API and IS-05 Connection API.
Resource Owner / End-User
An entity capable of granting a client access to a protected resource. When the resource owner is a person, it is referred to as an end-user.
The server hosting the Authorization API. It is responsible for the issuing of authorization codes and Access Tokens to registered clients, after successfully authenticating the client and resource owner and obtaining authorization.
The entity, usually a Web Application, Native application, or SPA (Single Page Application) that is attempting to act on
the user’s behalf or access a Protected Resource. A client must register with the Authorization Server before being able
to request tokens. Once registered, the client is assigned client credentials in the form of a
client_id and, for
confidential clients, a
client_secret. Clients are usually deemed to be Confidential or Public based on their
ability to authenticate securely with the Authorization Server.
Within NMOS this may be:
- a Node registering with a Registry using the IS-04 Registration API
- a monitoring application querying Nodes using the IS-04 Query API
- a connection control application using the IS-05 Connection API
A short-lived JSON Web Token (JWT) that may be used by a client to access Protected Resources on the Resource Server. It consists of a JSON object in which each key:value pair is referred to as a claim.
A Bearer Token is passed from the Authorization Server to the client after successful authentication of the request. Section 5.1. of RFC 6749 defines it as consisting of:
access_token- this is the JWT used to access a protected resource.
expires_atvalue - this coincides with the lifetime of the Access Token
token_type- always “Bearer” within the scope of this document
refresh_token(OPTIONAL) - this is present depending on the grant type. Refresh Tokens can be used to retrieve further Access Tokens from the Authorization Server if the shorter-lived Access Token has expired.
scope(OPTIONAL) - if the scope granted by the Authorization Server differs from the requested scope in the authorization request, the granted scope must be included in the Bearer Token.