Azure security baseline for Azure Functions well describes the security consideration in general while developing an Azure Functions application. In addition to that, Azure Functions offers a built-in authentication method through the functions key. If you use the OpenAPI extension for Azure Functions, you can define the endpoint authentication and authorisation for each API endpoint in various ways. You can even try them through the Swagger UI page. Throughout this post, I'm going to discuss six different approaches for access control to Azure Functions API endpoints using the OpenAPI extension.
This GitHub repository contains the sample app used in this post.
This provides sample app for authenticating Azure Functions endpoints by OAuth through the integrated Swagger UI.
Azure Functions OAuth Authentications via Swagger UI
This provides sample app for authenticating Azure Functions endpoints by OAuth through the integrated Swagger UI.
Prerequisites
To run this sample app on your local machine, you should be able to access Azure Active Directory in your tenant. Otherwise you can create a free Azure Account.
List of Authentications
- API Key in the querystring
- API Key in the request header
- Basic authentication
- Bearer authentication
- OAuth2 implicit flow
- OpenID Connect flow
- Easy Auth flow
The following OAuth2 auth flow doesn't support due to the limitations
- OAuth2 authorisation code flow - needs PKCE certificate that supports from OpenAPI spec v3.1.0
- OAuth2 client credentials flow - needs server/daemon
Related Read
OpenAPI Spec for Authentication
It could be a good idea to take a look at the authentication spec defined in OpenAPI before going further.
-
type: defines what type of authentication method will be used. Currently, it accepts API Key, HTTP, OAuth2, and OpenID Connect. But, the OpenAPI v2 spec doesn't support the OpenID Connect.
-
name: declares the auth key name. It's required for API Key.
-
in: defines the location of the auth key. It's required for API Key and accepts query, header, or cookie.
-
scheme: declares the auth scheme. It's required for HTTP auth and accepts either Basic or Bearer.
-
bearerFormat: uses JWT in most cases when using the Bearer token through the HTTP auth.
-
flows: is required for the OAuth2 auth. Its value can be implicit, password, clientCredentials, or authorizationCode.
-
openIdConnectUrl: is necessary for the OpenID Connect auth. However, it is advised to use either OAuth2 or Bearer auth for the OpenAPI v2 spec.
Based on the understandings above, let's apply the different auth approach to Azure Function endpoints through the OpenAPI extension.
APK Key in Querystring
This is the built-in feature of Azure Functions. Let's take a look at the code below. If you installed the OpenAPI extension, you could add the decorators. Spot on the OpenApiSecurityAttribute(...) decorator, which sets the value (line #6-9).
-
Type: SecuritySchemeType.ApiKey
-
In: OpenApiSecurityLocationType.Query
-
Name: code
Run the function app, and you will see the Swagger UI page.
Click the lock button on the right-hand side to enter the API key value. This value will be appended to the querystring parameter.
The result screen shows the API key passed through the querystring parameter, code.
API Key in Request Header
It's also the Azure Function's built-in feature. This time, set the value of the OpenApiSecurityAttribute(...) decorator like below (line #6-9).
-
Type: SecuritySchemeType.ApiKey
-
In: OpenApiSecurityLocationType.Header
-
Name: x-functions-key
Run the function app and see the Swagger UI page.
If you want to authenticate the endpoint, enter the API key value to the field, labelled as x-functions-key.
As a result, the API key was sent through the request header, x-functions-key.
Basic Auth Token
Let's use the Basic auth token this time. Set the property values of OpenApiSecurityAttribute(...) (line #6-8).
-
Type: SecuritySchemeType.Http
-
Scheme: OpenApiSecuritySchemeType.Basic
As this is not the built-in feature, you can use this approach for additional auth methods or replace the built-in feature. If you don't want to use the built-in API key, you should set the auth level value of the HttpTrigger binding to AuthorizationLevel.Anonymous (line #12).
Run the app to see the Swagger UI like below.
To authenticate your endpoint, you should enter the Username and Password, added to the Authorization header.
The result screen shows the request header of Authorization with the base64 encoded value.
Then, you should validate the auth details with your custom logic.
Bearer Auth Token
Similarly, this time, let's use the Bearer auth token. Set the property values of OpenApiSecurityAttribute(...) (line #5).
-
Type: SecuritySchemeType.Http
-
Scheme: OpenApiSecuritySchemeType.Bearer
-
BearerFormat: JWT
You now know how to set the auth level of the HttpTrigger binding to AuthorizationLevel.Anonymous (line #13).
Run the function app and see the Swagger UI page.
During the authentication, you are asked to enter the Bearer token value. The Authorization header will add the value.
The result screen shows the JWT value in the Authorization header.
You should decode the JWT and find the appropriate claims and validate them for further processing.
OAuth2 Implicit Auth Flow
Although there are many ways in the OAuth2 authentication flow, I'm going to use the Implicit flow for this time. Set the properties of OpenApiSecurityAttribute(...) (line #6-8).
-
Type: SecuritySchemeType.OAuth2
-
Flows: ImplicitAuthFlow
Auth level is also set to Anonymous (line #12).
You can see ImplicitAuthFlow as the flow type. Since it uses Azure Active Directory, it sets AuthorizationUrl, RefreshUrl, and Scopes values. It also takes the single tenant type, which requires the tenant ID (line #3-6, 10, 14-15). Scopes has the default value (line #17).
Run the function app and check the Swagger UI page.
When you click the lock button, it asks you to enter the client ID value, redirecting you to sign in to Azure Active Directory. Then, you will get the access token.
The result shows the Authorization header with the access token in the JWT format.
That JWT is now decoded and verified for further processing.
OpenID Connect Auth Flow
Finally, let's use the OpenID Connect auth flow. OpenApiSecurityAttribute(...) contains the following definitions (line #6-9).
-
Type: SecuritySchemeType.OpenIdConnect
-
OpenIdConnectUrl: https://login.microsoftonline.com/{tenant_id}/v2.0/.well-known/openid-configuration
-
OpenIdConnectScopes: openid,profile
The {tenant_id} value, of course, should be replaced with the real tenant ID. With this OpenID Connect URL, it automatically discovers the OAuth2 auth flows. Then, set the auth level to Anonymous (line #12).
Run the function app and find the Swagger UI page.
Unlike other auth flows, this OpenID Connect auth flow shows two methods. The first one is the authentication code flow, and the other one is the implicit flow. Let's use the second one and enter the client ID value. It will redirect you to Azure Active Directory to sign in and give you the access token.
Once execute the endpoint, the access token is passed through the Authorization header in the JWT format.
Decode and validate the token for further processing.
So far, we've covered six different ways to authenticate the HTTP trigger endpoints with the OpenAPI extension. These six ways are the most commonly used ones. Therefore, if you need, you can pick up one approach and implement it.
Justin Yoo
