Security Schema, env/server dependent

[DavDeDev]

I have a microservice with endpoints secured using OAuth 2.0. The service runs in three different servers/environments (Local, Dev, and SIT), and each environment uses a different authorization server with its own Auth URL, Access Token URL, etc. Is there a way to define a single security schema that can adjust these URLs automatically based on the selected server/environment?

[karenetheridge]

tokenUrl and its friends can be indicated in the OAD as a uri-reference. This should be resolved against the the canonical uri of the OAD itself, which in 3.1.x is only provided to the implementation out-of-band as a retrieval uri ("the URL where this document was found") but in 3.2 the $self property is being added for the document itself to state what its identifier should be (and if that is also a uri-reference, that's resolved against the "retrieval uri").

Server urls in the root, path-item object and operation object already exist, but I believe these would only be used for processing the runtime request's URI (e.g. to match a request to the appropriate /paths/* entry in the document), not security URIs.

[handrews]

The same one you're using for the rest of the API? Although I don't know how that gets impacted by servers at the operation level (I'm not even sure what the use case for those is, tbh).

I would probably make these sorts of URLs non-relative unless you want them to differ for different deployments, in which case you probably know which server URL to use. In addition to these being runtime endpoints of some sort (URLs used during API interaction rather than URIs used when the OAD is loaded), my feeling is that having them be server-relative is more flexible than OAD-relative. But I'm not entirely sure I'm right.

[karenetheridge]

off in the corner fixing security uris in my implementation to work relatively with server urls, which means saving a lot more state information between various method calls...

[handrews]

@karenetheridge This is all my interpretation, btw. That doesn't necessarily mean it's correct.

[karenetheridge]

This could probably use a clarification then. I'm looking through the schema at all the uri-references, and some of them seem intuitively that they'd resolve against the OAD itself with the retrieval uri and $self (e.g. jsonSchemaDialect, /info/termsOfService) and some against an http request at runtime, but I don't think the revisions for 3.2 about URIs differentiates between the two types.

[karenetheridge]

I put up my initial thoughts here - #4926