Initiate authorization for a UI-less node

[cristian-recoseanu]

How does a user initiate the authorization flow for an NMOS node which does not have a UI (e.g. pure hardware device like an SFP)?

Do we need to specify something like an /authorize endpoint which will kick start the process (redirect to the authorization server with the correct grant type and scopes)?

[dannymeloy]

Hi Cristian. Yes exactly, the device would likely support an endpoint (e.g. /login ) which would then provide a convenient means of redirecting a user's browser to the Auth Server to initiate the auth code flow. The device would be expected to host an authorization endpoint (e.g. /authorize) anyway in order to then receive the Authorization Code and swap it for an Access Token. Without the ability to host endpoints, the authorization could not be achieved using the standard Auth Code flow.

[cristian-recoseanu]

Thanks @dannymeloy! So is this mentioned anywhere in the spec? Do we need to make it a standardised endpoint? Some things like low powered devices might just have the NMOS API and that's it (no Web UI at all).

[dannymeloy]

The endpoint is mentioned here (https://github.com/AMWA-TV/nmos-authorization/blob/v1.0-dev/docs/4.2.%20Behaviour%20-%20Clients.md#client-endpoints).

I think it may be beneficial to assign a fixed value to this endpoint, for the sake of easing automation for instance. We could say that "If the redirect endpoint is hosted then it MUST be found at /oauth" for example). We may have to think how that might affect which scopes are passed upstream for instance, but it has the potential to help with integration.

[cristian-recoseanu]

I see. I agree we should consider making it a fixed value which could then be wrapped by a control system with a UI in a consistent way (items awaiting authorization would appear in a list and you can click on them in the control system and click on the Authorize button which would then redirect to the node /oauth endpoint potentially).

[lo-simon]

Our idea is the user-agent (e.g. broadcast controller) has a special endpoint (e.g. /start_authorization_flow), which is configured in the Node. When Node startup, it will construct the authorization_code_uri and send it to the user-agent via this special endpoint to kick start the authorization code flow.

example of authorization URI
https://<authorization_server>/authorize?client_id=<client_id>&redirect_uri=https://<node-redirect-uri>&response_type=code&code_challenge=<code_challenge>&code_challenge_method=S256&state=<state>&scope=<scopes>

End-user can then authorize the Node by interacting with the Authorization Server via the User-agent.
Authorizaton Server will then redirect the Authorization code back to the Node via the User-agent.

[cristian-recoseanu]

I think in the past activities have been cautious about specifying broadcast controller features. This would create a dependency on the broadcast controller for the node which wouldn't really work in an environment where you may not have a broadcast controller (p2p mode).

[lo-simon]

Broadcast controller is just an example of an User-agent (a browser), which is just providing the UI feature for the Node. And Yes the Node will have dependency of the user-agent. I would like to clarify my understanding of your idea,

1. End-User/User-agent (System Controller) trigger the Node /authorize endpoint to initailise the authorizate flow
2. Node responses User-agent with the authorization_code_uri
3. User-agent use the authorization_code_uri to start the authorization code flow
4. Authorization Server responses with a fixed (defined response, rather than a html page?)
5. System Controller build up a list of awaiting authorize Nodes
6. End-user accept the consent, and authorizate the Nodes (send bulk authorization to Authorization Server?)
7. Authorization Server redirect the authorization codes to each Nodes
8. Nodes can then exchange Authorization Code with Access Token

[cristian-recoseanu]

It would be more like:
User can use a "tool" (Browser, Postman, WebApp, ControlSystem) to send a request to the node's /oauth well known endpoint.

This would tell the node it needs to initalize the authorization flow and redirect to the authorization server with the grant and scopes.

The user enters credentials and allows the authorization to happen.

The node gets back the auth code transparently and it gets to retrieve the token.

I don't really see why the "tool" would need to intercept the authorization code and intervene in that part of the process.

[lo-simon]

Please find attached animation powerpoint Grant_access_to_UI-less_NMOS_Node.pptx on showing how an UI-less NMOS node can be authorized.

There are area Danny and Cristian have pointed out in the previous conversation, such as need to standardize the Client’s /oauth endpoint. While we are creating the powerpoint, we also realised the Authorization Server’s /clients endpoint will need to be standardize too.

Client Credentials Grant may also be the solution for UI-less client, see #62

[peterbrightwell]

Moved to #76