0
votes

I was reading the OAuth 2.0 RFC 6749. In section: (Protocol Endpoints)[https://tools.ietf.org/html/rfc6749#section-3] it mentions that the Authorization server needs an authorization endpoint. In the application I am building, there is a need for another client that wants a different way of completing the authorization code flow, hence was considering two options:

  1. expose a new endpoint on a different path

  2. retain existing endpoint (/authorization) but watch for headers that the new client will provide

The spec does not say anything about exposing multiple Authorization endpoints. Was wondering if it would be compliant?

1

1 Answers

0
votes

I think that a "different way of completing the authorization code flow" may well be out of compliance with the specifications. Depends on the details. Generally, the Authorization Server may manage the authorization code flow internally as it sees fit based on "policy". However, externally, authorization code flow is well defined.

As the specifics of the Authorization_endpoint (RFC 6749): "The means through which the OAuth Client obtains the location of the Authorization_endpoint are beyond the scope but the location is typically provided in the service documentation."

The location may be defined in OpenID Connect Discovery or provided in the service documentation.

-jim