Skip to content

Confusion around Authentication Schemes Flows #41

@alukach

Description

@alukach

In the Authentication Schemes object, we have flows described as Map<string, (OAuth2 Flow Object|Signed URL Object)>. I interpret that as a mapping between a string and either the OAuth2 flow object or Signed URL object.

However, in the Scheme Definition examples, we have the oauth2 example written as such:

authentication/README.md

Lines 127 to 137 in faa9897

"auth:schemes": {
"oauth": {
"type": "oauth2",
"description": "requires a login and user token",
"flows": {
"authorizationUrl": "https://example.com/oauth/authorize",
"tokenUrl": "https://example.com/oauth/token",
"scopes": {}
}
}
}

In ☝, the flows object appears to be a OAuth2 Flow Object, not a mapping of a string to the OAuth2 Flow Object.

Reviewing the signedUrl scheme type example, we do see a mapping:

authentication/README.md

Lines 181 to 212 in faa9897

"auth:schemes": {
"signed_url_auth": {
"type": "signedUrl",
"description": "Requires an authentication API",
"flows": {
"authorizationCode": {
"authorizationApi": "https://example.com/signed_url/authorize",
"method": "POST",
"parameters": {
"bucket": {
"in": "body",
"required": true,
"description": "asset bucket",
"schema": {
"type": "string",
"examples": "example-bucket"
}
},
"key": {
"in": "body",
"required": true,
"description": "asset key",
"schema": {
"type": "string",
"examples": "path/to/example/asset.xyz"
}
}
},
"responseField": "signed_url"
}
}
}

However, in ☝ I'm confused about the meaning of authorizationCode. Does it relate the the oauth2 authorization code flow (which happens to be omitted from the example)?

Additionally, it seems likely that the endpoint that performs URL signing would also require authentication. It seems like this is what authorizationCode could be relating to, but I would find that to be a strange way of modeling a flow's requirements.

It seems as though:

  1. The flows type should simply be OAuth2 Flow Object|Signed URL Object, not a mapping. If this is correct, then calling it flows rather than flow feels a bit strange.
  2. The signedUrl scheme should include support for its own auth:refs

If this is correct, then I suppose a complete signedUrl example could look like the following:

"auth:schemes": {
  "signed_url_auth": {
    "type": "signedUrl",
    "description": "Requires an authentication API",
    "flows": {
      "authorizationApi": "https://example.com/signed_url/authorize",
      "method": "POST",
      "parameters": {
        "bucket": {
          "in": "body",
          "required": true,
          "description": "asset bucket",
          "schema": {
            "type": "string",
            "examples": "example-bucket"
          }
        },
        "key": {
          "in": "body",
          "required": true,
          "description": "asset key",
          "schema": {
            "type": "string",
            "examples": "path/to/example/asset.xyz"
          }
        }
      },
      "auth:refs": ["oauth"],
      "responseField": "signed_url"
    },
    "oauth": {
      "type": "oauth2",
      "description": "requires a login and user token",
      "flows": {
        "authorizationUrl": "https://example.com/oauth/authorize",
        "tokenUrl": "https://example.com/oauth/token",
        "scopes": {}
      }
    }
  }
}

Thanks for the work done on this spec so far! It feels much needed.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions