Corrections in the Why No OAuth page #49
Description
I have had the question from multiple people why S2 doesn't use OAuth 2.0. I often refer to this page which is great. There are clear arguments in this page, but also some that are more easily refuted. I think it would help to remove those to keep the message strong.
I'll quote them here and respond to them, and would be happy to make a PR to change the page according to consensus.
Using OAuth 2.0 will require the end user to enter more information from S2ServerNodeUI to the S2ClientNodeUI compared to our custom pairing specification. The user has to provide the Authentication server URL, the Resource Server URL, the Websocket URL, and copy the token to S2ClientUI.
I think all hardware and software that already has an IP stack will be easily able to provide at least a local web-ui. Any tiny microcontroller can accommodate a webserver, and since currently the RM needs to be able to act as both the S2ClientNode and the S2ServerNode in the pairing process, the RM is going to have to incorporate a webserver anyway. Furthermore, asking a user to manually enter data is a bad User Experience. It would be a shame if the interoperability of hardware is weakened by the fact that the user is not able/willing to enter data manually. A very simple web-ui and app (could be local network only) that does this for the user is easy to build and significantly improves the UX for the end-user. It also removes this argument, as any information can be sent automatically with a few button clicks, rather than typing in manually.
The communication layer of S2 specifies the use of websockets. OAuth 2.0 does not have a (out of the box) solution for communicating to the client where the websocket connection should be opened. Hence, this requires the end user to manually configure the websocket URL on the client.
OAuth2 is HTTP, websockets are HTTP as well. OAuth handles the authentication at the HTTP level and therefore takes place BEFORE the websocket connection is established. There is no need for OAuth2 to accomodate websockets specifically.
S2 requires the protocol to be usable in a local situation, without internet connection. S2 does accept self-signed certificates in these specific situations. OAuth2.0 is not clear about this situation. As a result it is not clear whether it's possible to use OAuth 2.0 in this situation.
You can run an OAuth identity server locally if needed. S2 requires a discovery and authentication server to run locally as well, so essentially that is the same. Self-signed certificates concern HTTPS/TLS, not OAuth. So there is no reason why OAuth can't be used with self-signed certificates. The issue is trusting self-signed certificates with any HTTPS setup. Only in use-cases where self-signed certificates for the OAuth server are used, would we need to make sure that the certificate for the OAuth server is validated, but that could be the same as the mechanism for the pairing server, and is only relevant with non-internet connected situations, in which is an edge-case where asking the user to manually add the certificate in the trust list and keeping track of it in the RM/CEM could be an additional requirement.
In addition, to support the local-local scenario, the S2ServerNode needs to run the authorization server locally as well. Such a server is not necessarily the most resource intensive application but still requires the server to be packed with extra code.
Now we also need to run a webserver for the pairing component, so whether its an OAuth server or an S2 pairing/discovery/authentication server makes no real difference.