In order to support WoT Discovery security bootstrapping (e.g. for a third party app or cloud service to gain access to the Thing Description of a Thing), an OAuth2 client (i.e. the app or service) needs to discover the authorization and token endpoints of the authorisation server (i.e. gateway) in order to gain a user's authentication and request an access (and refresh) token.
RFC 8414 defines a standard metadata format and well-known URL which a client can use to discover this information about an authorisation server.
Note that this technically doesn't fully solve the problem of discovering the authorization server from a Thing Description URL, because in OAuth2 the resource server (in this case the gateway serving Thing Descriptions) can exist at a separate origin to the authorization server (which issues authentication tokens). In the case of the gateway they exist at the same origin, but a third party OAuth2 client has know way of knowing this.
In order to support WoT Discovery security bootstrapping (e.g. for a third party app or cloud service to gain access to the Thing Description of a Thing), an OAuth2 client (i.e. the app or service) needs to discover the authorization and token endpoints of the authorisation server (i.e. gateway) in order to gain a user's authentication and request an access (and refresh) token.
RFC 8414 defines a standard metadata format and well-known URL which a client can use to discover this information about an authorisation server.
Note that this technically doesn't fully solve the problem of discovering the authorization server from a Thing Description URL, because in OAuth2 the resource server (in this case the gateway serving Thing Descriptions) can exist at a separate origin to the authorization server (which issues authentication tokens). In the case of the gateway they exist at the same origin, but a third party OAuth2 client has know way of knowing this.