Step 6: The security object (OpenAPI tutorial)
Swagger UI provides a “Try it out” feature that lets users submit actual requests. To actually submit requests that are authorized by your API server, the spec must contain security information that will authorize the request. The
security object specifies the security or authorization protocol used when submitting requests.
- Which security scheme?
- API key authorization
- Security object
- Referencing the security scheme in components
- Swagger UI appearance
- Checking to see if authorization works
- Troubleshooting issues
Which security scheme?
REST APIs can use a number of different security approaches to authorize requests. I explored the most common authorization methods in Documenting authentication and authorization requirements. Swagger UI supports four authorization schemes:
- API key
- OAuth 2.0
- Open ID Connect
In this tutorial, I’ll explain the API key method, as it’s the most common and it’s what I’m most familiar with. If your API uses OAuth 2.0 or another method, you’ll need to read the Security Scheme information for details on how to configure it. However, all the security methods largely follow the same pattern.
API key authorization
The sample OpenWeatherMap API we’re using in this course uses an API key passed in the URL’s query string (rather than the header). If you submit a request without the API key in the query string (or without a valid API key), the server denies the request.
At the root level of your OpenAPI document, add a
security object that defines the global method we’re using for security:
security: - app_id: 
app_id is the arbitrary name we gave to this security scheme in our
securitySchemes object. We could have named it anything. We’ll define
All paths will use the
app_id security method by default unless it’s overridden by a value at the
path object level. For example, at the path level we could overwrite the global security method as follows:
/current: get: ... security: - some_other_key: 
weather path would use the
some_other_key security method, while all other paths would use the globally declared security,
Referencing the security scheme in components
components: ... securitySchemes: app_id: type: apiKey description: API key to authorize requests. If you don't have an OpenWeatherMap API key, use `fd4698c940c6d1da602a70ac34f0b147`. name: appid in: query
Properties you can use in the
securitySchemes object include the following:
type: The type of authorization —
description: A description of your security method. In Swagger UI, this description appears in the Authorization modal (see screenshot below). CommonMark Markdown is allowed.
name: The name of the header value submitted in the request. Used only for
in: Specifies where the security key is applied. Options are
cookie. Used only for
scheme. Used with
bearerFormat. Used with
flows(object): Used with
openIdConnectUrl: Used with
Swagger UI appearance
In the Swagger UI, you see the
description and other security details in the Authorization modal (which appears when you click the Authorization button):
After users enter an API key and clicks Authorize, the authorization method is set for as many requests as they want to make. Only when users refresh the page does the authorization session expire.
Checking to see if authorization works
When you submit a request, Swagger UI shows you the curl request that is submitted. For example, after executing a weather request, the curl is as follows:
curl -X GET "http://api.openweathermap.org/data/2.5/weather?zip=95050%2Cus&appid=fd4698c940c6d1da602a70ac34f0b147&units=imperial"
&appid=fd4698c940c6d1da602a70ac34f0b147" indicates that the API key is being included in the query string. (For more on curl, see Make a curl call.)
If you have security correctly configured but the requests are being rejected, it could be due to a CORS (cross-origin resource sharing) issue. CORS is a security measure that websites implement to make sure other scripts and processes cannot take their content through requests from remote servers. See CORS Support in Swagger UI’s documentation for details.
64/96 pages complete. Only 32 more pages to go...
If you would like to contribute back to say thank you for the API documentation course, click the Donate button below. Alternatively, to contribute content, such as a tutorial or a new section, contact me with your ideas. You can also submit a pull request in the GitHub repo to make your contribution. Even if you want to just fix a typo or add a sentence here and there, it's always welcome.
I'd Rather Be Writing Newsletter
Get new posts delivered straight to your inbox.