Google, Azure AD, AWS Cognito
Give Google its OAuth client id, Azure AD its application, tenant, audience and issuer, Cognito its user pool and region. The signature, the expiry and the audience of every token are checked.
Security
Single Sign-On
Let people sign in with Google, Microsoft or AWS, and use your API Maker permissions for them.
Your app signs users in with Google, Azure AD or AWS Cognito and sends the token it gets. API Maker checks it with the keys of the provider, finds the user in your own table, and runs the call with the groups of that user. You store no passwords. For anything else, write your own token provider.
See it live
Step through it, slow it down, or open the full canvas.
api-maker/features/single-signLive- Providers
- 3Google · Azure · AWS
- Passwords
- 0stored by you
- Groups
- —of the user
- Refused
- 0401
Users sign in with the account they have. Google, Microsoft Azure AD or AWS Cognito signs the user in and gives your app a token. No password for you to store.
How it works
Users sign in with the account they have.
Google, Microsoft Azure AD or AWS Cognito signs the user in and gives your app a token. No password for you to store.
The token goes in a header.
x-google-authorization, x-azure-authorization or x-aws-authorization. The settings of each API name its auth providers, else the secret does.
Verified with the keys of the provider.
For Google: the signature, the expiry, and that the token was made for your client id. Azure uses the keys of your tenant and app, AWS your Cognito user pool.
Mapped to your groups.
A field of the token, here the email, finds the user in your own table. Its groups column gives the API Maker groups, * gives all of them.
The call runs with those permissions.
Tables, columns and APIs follow the groups of the user. Your code reads the verified token in g.req.auth.authGoogle.
Everything else gets 401.
No token, a token that is invalid or expired, a user without a row or without groups: the request stops before any data is read.
What you get
Custom providers
Write a token generator and a token validator in your language, with its packages, for tokens of any other system. The validator's result lands in g.req.auth.authCustom.
Per API or for all
The auth providers of your secret apply to every API, and the settings of an API, a table or a database can name others.
An example
Company sign-in for an internal tool
Employees open an internal dashboard and sign in with their Microsoft account. The dashboard sends the Azure AD token, API Maker finds each employee in the staff table, and their department decides which APIs and fields they can use.
import * as T from 'types';let googleTokenGenerator: T.IAuthTokenGoogle & { name: string } = { name: 'google_users', clientId: '1234567890-abc.apps.googleusercontent.com', sourceFieldOfUniqueId: 'email', groupsDataSource: { instance: 'mysql', database: 'crm', table: 'users', targetFieldForUniqueId: 'email', groupsColumn: 'groups', },};module.exports = googleTokenGenerator;GET /api/schema/admin/mysql/crm/ordersx-am-authorization: <API user token of the app>x-google-authorization: <ID token from Google>Watch it
On the real admin panel, with real data.
Good to know
- A signed-in user needs a row in your groups table, with groups, to reach APIs that require their token.
Questions
Do I still need an API user token?
Yes for token protected APIs: x-am-authorization identifies your app, the provider token identifies the person.
Where does my code find who is calling?
In g.req.auth: authGoogle, authAzure, authAWS, authCustom, and authAMDB for users of your own table.
What happens with an invalid token?
The call stops with 401 before any data is read: no token, a wrong or expired token, or a user without a row or groups.