Decoupling your Authorization layer with Cloud Endpoints
Abstract
The main purpose here is to avoid implementing any authentication logic in your backend services. Achieving effectively decoupling the authorization layer from the backend code.
STOP THIS MADNESS AND SHOW ME THE CODE!
ESP validates that the JWT was signed by Firebase and that the
iss(issuer) claim in the JWT, which identifies your Firebase application, matches thex-google-issuersetting in the service configuration
It essentially will keep us from written the following backend logic. But also will bring additional features to our APIs such as monitoring and logging in Cloud Endpoints.
The Extensible Service Proxy validates the JSON Web Token on behalf of your API, so you do not have to add any code in your API backend to process the authentication. But you do have set the proper OpenAPI configuration.
Security Definitions
OpenAPI (swagger) let us use schemas to describe our security. So, securityDefinitions is where we define the security schemas our API supports.
Security Schemes
Each security scheme can be of type:
- http, for Basic and Bearer and other http authentication schemes
- apiKey, for API keys and Cookies Authentication
- oauth2, for OAuth2
- openIdConnect, for OpenID Connect Discovery
We can apply security schemes to API level or operations level. Here we’ll be using the API level approach.
Firebase JWT
Firebase JSON Web Tokens (JWT) expires after one hour then you got to use the refresh token to get a new JWT. When the token expired it cannot longer be used to access your API in Cloud Endpoints and a custome error will be return.
ID token revocation
What it truly amaze me from decoupling the authentication layer from the backend service code is that we get ID token revocation for free. Since Firebase JWT are stateless. The only way to check token status is asking for it to the Firebase Authentication Backend. Performing this check is an expensive operation, requiring an extra round trip. But since our authentication layer is now host on the Cloud Endpoints, the ESP makes this validation without compromising the application performance.
Firebase Security Rules are another way to avoid this extra network round-trip.
The ESP,
- Validates your JWT in a performant way
- Caches the public keys for 5 minutes
- Caches the validated JWT for 5 minutes or until the token expiry.
Getting Authenticated Requests in the Backend Service
If token id verification goes successful ESP forwards all the headers it receives. But there is one exception to the rule, Cloud Endpoints overrides the Authorization header when the backend address is specified by x-google-backend. In that case you need to be checking for the authenticated results in X-Endpoint-API-UserInfo header.
