How can I specify default ids for security definitions in an OAS?

[kurtkanaskie]

Given I have this basic security definition in my spec, is there a way I can specify default values for the clientId and clientSecret and even username and password?

"securityDefinitions": {
    "OauthSecurity": {
      "type": "oauth2",
      "flow": "password",
      "tokenUrl": "https://ORG.apigee.net/BASEPATH/v1/oauth/token",
      "scopes": {
        "user": "User scope"
      }
    }
  },
  "security": [
    {
      "OauthSecurity": [
        "user"
      ]
    }
  ],

Its tedious to always enter that information in this dialog.

[Marsh]

@Kurt Kanaskie are you asking if there's a way for the tooling to store these secrets for you so you can get back to work faster? Guessing you would benefit from this in both the Spec Editor and the API reference docs on a portal?

[kurtkanaskie]

Well yes on the tooling. But was really asking is it part of the specification, just like I can specify a default for query parameters?

For docs on a portal, it would be very useful because prospective users could just try out the API without having to register. I could also get some analytics on number of visitors too.

[Marsh]

`default` is not actually a default value for clients, it indicates what the server assumes if a value is not provided. A good example would be the `limit` in a search query defaulting to 10 results unless the client specifies something else.

In this case, there is no server-assumed-default, these values are always required. If tools like Swagger UI wanted to pre-supply some values (tricky to do, since those are secrets and will quickly be compromised), that's up to those tools.

From the Apigee Edge perspective, we've been thinking about possible futures where any admin user might also be automatically provisioned with consumer credentials, and that those might be auto-populated for both the spec editor and for the developer-portal docs experience (i.e. all logged in devs could choose creds from their existing applications). Would that solve your problem?

[kurtkanaskie]

I understand the "default" nuance, but it does populate params in the spec, which is convenient. Perhaps I should have asked about "example" IDs.

So then its back to tooling, similar to what Edge management APIs do.

[Marsh]

If `default` is populating example parameter values, that's a tooling choice that's arguably inappropriate.

The current v3 draft of the OpenAPI Specification offers some clarity by adding in the example object, see: https://github.com/OAI/OpenAPI-Specification/blob/OpenAPI.next/versions/3.0.md#example-object-exampl...