What could be fixed in Security in Moonwalk?

[darrelmiller]

• Workflows is trying to describe token acquisition sequences. What can we do to help?
• Attach scopes to operation + subsets of a model
• Align with the security SIG

[darrelmiller]

@whitlockjc Add your thoughts here please!

[whitlockjc]

Security Schemes (formerly known as "Security Definitions") provide a way to describe the security scheme(s) used by your API. Unfortunately, the types supported by OpenAPI are not only limited but they often tie the credential location to the Security Scheme type. This proposal will add a generic way to define where a credential is and its format so that the consumer can have complete control over where credentials are used in their API. Not only would this allow consumers to specify their own Security Schemes without OpenAPI having to be the gatekeeper, but it also allows a level of flexibility not available now. There have also been extra Security Scheme properties that have been tacked on to support the growing needs of consumers, which would be alleviated (or moved in this case).

Note: Sourced from the Motivation section of the original proposal.

[darrelmiller]

Stu: How do influence the community to create more consistent implementations? Lots of variations of OAuth2.
Jeremy: Discussed the proposed solution. Cleaned up structure with a config and credentials object. Also made type extensible.
Dan: We need a better model for Authorization.
Marsh: Does this need to be part of OpenAPI? Could this be used for other scenarios? What are the scenarios it is used for?
Darrel: Discovery of how to provision an api key, or an OAuth2 client application?
Marsh: Other metadata, how long do tokens last? How often do I need to rotate secrets?
Dan: Supportive of considering externalizing schema. Also, could security events be described in a different document.
MikeR: AsyncAPI has the notion of bindings for protocol specific information that defer to an external document.
Dan: Multiple documents forces the separation of concerns. Would we need to support embedding to help customers who really want everything in one file.
Ralf: likes the idea of separating AuthN and API Design
MikeR: + 1
Darrel: Is AuthZ part of the API design or Security concern?
Dan says yes, Ralf says no.
Ben: What are the concerns of an OAS document?
MikeR: Pulling security (and potentially other areas) out of "core" might enable us to iterate on moonwalk faster

[mcrobbj]

The security section assume that there is just a single Idp across all the environments. You can only define a single authorisation and token endpoint. Could it be like the servers section for the API so that you can have environment specific idp endpoints.

Also there is mention of mtls being able to be defined but I have never managed to find an example. of how to use it in the operations level. So I only have the following for the security schema:
mutualTLS:
description: Mutual TLS
type: mutualTLS
scheme: mutual

[rafalkrupinski]

subsets of a model

Is that something like readOnly/writeOnly from OAI 3.0?

[handrews]

3.x issue move to Moonwalk:

• Server-specific Security Requirements OpenAPI-Specification#2628

[mikekistler]

Hi folks, I want to chime in here with another perspective. I think it would be really nice if OpenAPI security schemes could describe "real world" authn/authz flows like cookie authentication. I chatted about this recently with @darrelmiller and we concluded that the only way to describe this in OpenAPI 3.x is with:

components:
  securitySchemes:
    cookieAuth:
      type: apiKey
      in: cookie
      name: token

which to me seems totally inadequate.

For example, it does not indicate what operation is used to obtain the cookie -- typically this is something like "/login".

Also, "apiKey" seems wrong. I think of getting an API key from the service through some out-of-band channel.
Cookies are nothing like that.

Does anyone else think that this is a problem that needs fixing in Moonwalk?

[SensibleWood]

Ah it was this puppy: OAI/OpenAPI-Specification#1464 👈 @handrews revisited it recently and pointed out it's already possible with the JSON Schema reference included in 3.1. Looks like the only work to do is get every open finance ecosystem to uplift to 3.1.0...

[SensibleWood]

@orubel I wasn't making an reference to roles at all in what I was proposing. @ralfhandl asked us where we could contribute, I suggested a place I could, nothing to do with roles.

Describing the shape of a JSON Web Token is important for the reasons I mentioned as it helps people implement standards like PAR, JAR, OIDC Request Objects, OIDC ID Tokens, etc.

At the moment there's a basic disconnect in the API descriptions for these standards sub version 3.1, namely tooling makers can't pick up the description and reflect the design in a fully-formed Scheme Object. It's all implied in the way I described.

Anyway, looked like v3.1 gives open finance ecosystems what they need.

[handrews]

@orubel we might have limited PRs to keep people from opening PRs on the initial proposal thinking it was the actual draft... in general, you do not need to be an official collaborator to make PRs here. Most of the work is happening in discussions right now so it's probably better to continue here or start a new discussion. The only PRs we're doing right now are for ADRs (Architectural Decision Records, of which we have I think only one very minor one so far).