Currently, interacting with the Tornjak backend secured with OAuth2 requires a client knows ahead of time how to obtain an access token. The backend exposes no information on how to authenticate. This requires the Tornjak frontend and the Tornjak manager to be configured or given this information ahead of time, which leads to double-configurations in, say, the helm charts.
If the backend is implemented to expose Metadata as outlined in RFC 9728: OAuth 2.0 Protected Resource Metadata, this may ease configuration requirements on clients interacting with the backend.
Currently, interacting with the Tornjak backend secured with OAuth2 requires a client knows ahead of time how to obtain an access token. The backend exposes no information on how to authenticate. This requires the Tornjak frontend and the Tornjak manager to be configured or given this information ahead of time, which leads to double-configurations in, say, the helm charts.
If the backend is implemented to expose Metadata as outlined in RFC 9728: OAuth 2.0 Protected Resource Metadata, this may ease configuration requirements on clients interacting with the backend.