Sign-In for Your Users: DB Token Generator, Custom Tokens and SSO

Intro

0:00 Your app has people : customers, staff, partners. Auth providers let them sign in, and tell every API who is calling, without one line of login code.

Login code, again

0:11 Every project writes it again : a login endpoint, password hashing, JSON web tokens and their refresh, a check that the user is still allowed in, and the same checks copied into every endpoint. One shortcut, and passwords leak or tokens never expire. With API Maker, a provider points at your users table, passwords are hashed by the schema, tokens are signed, refreshed and checked on every call, and an API asks for a person with one setting.

0:41 In this video : the Auth Providers page, a DB token generator over the customers of PostgreSQL, a customer signing in, an API that wants a signed-in customer, a custom token generator with your own sign-in code, and single sign-on.

The page

0:56 Auth providers are in the Security panel. The page lists the providers of the account : none yet. Add offers five kinds : a DB token generator for people stored in your own table, a custom token generator for your own sign-in code, and AWS Cognito, Azure AD and Google for single sign-on.

Two tokens

1:17 A request can carry two tokens. The API user token, in x am authorization, says which application calls. The person token, in x am user authorization, says who is using it. The groups decide what the application may call, and the person decides whose data it is. Single sign-on tokens come in headers of their own : x aws, x google and x azure authorization.

DB token generator

1:45 Calm Home keeps its customers in PostgreSQL. For this video they get a password column, and the schema of the table hashes it : every write through API Maker stores a keyed hash, never the password as typed. Update. No hashing library, no salt to manage, no plain text to leak. Add, DB token generator. Its basic info names the table, the username column, the password column, and a condition : only active customers may sign in.

2:15 The select decides which columns travel in the token, and the token lives an hour. The fields generator runs every time a token is made or refreshed. It gets the row of the customer and returns what the app needs without another call : the customer id, the loyalty tier and a display name. Save, and customer login is on the list.

Sign in

2:38 Signing in is the Get token system API. In API Testing, system APIs, Get token. The body names the provider, the e-mail and the password. Send, and Kabir gets a token, a refresh token, and the lifetime : an hour. Inside the token : the columns of the select, and a fingerprint of the password, never the password itself. Token data holds what the fields generator returned, and the token is signed by the installation, with its issuer and its expiry.

3:12 A wrong password gets no token, and neither does Ishaan, whose account is blocked : the condition stops him. Both answers say nothing about which part was wrong.

APIs for persons

3:23 Now an API that wants a signed-in customer. A custom API, My Profile : its basic info names the provider in auth providers. Its code reads the customer from g dot req dot auth. Save. In API Testing, the person header lists the customers of the provider, pick Kabir, and send : the profile of Kabir. The same API from an app : with the API user token only, it answers four oh one, asking for the person token.

3:55 With Kabir's token, his profile. The person is checked on every call. Block Kabir with an update through API Maker, and his token stops working on the next call. A change made straight in the database is seen within a minute. Tokens are short on purpose. The refresh token, sent to the same Get token API, returns a new pair, as long as the person is still allowed in and the password did not change.

Custom token generator

4:23 Some sign-ins are not a username and a password. Calm Home lets a guest follow an order with the e-mail and the order number. A custom token generator has two functions. The token generator checks the e-mail in PostgreSQL and the order in MySQL, and signs a token with g dot sys dot system dot hash. The token validator runs on every call, checks the signature and the expiry, and returns the claims, or false.

4:51 Save. Try it from the list. An e-mail and an order number, send : a token. The Order Status API asks for this provider and reads the order id from g dot req dot auth dot auth custom. A forged token gets four oh one : the validator said no.

Single sign-on

5:10 For single sign-on, add Google. Its settings are the client id of your Google app, the claim that names the person, and, optionally, a table that holds the groups of each person. Save. API Maker checks the Google token with the published keys of Google, its audience and its expiry, on every call. Azure AD and AWS Cognito work the same way. Give Google its client id and Azure its audience : without them, a token made for another application would be taken, and the security report flags the provider.

5:48 Three kinds of providers, one list.

g.req.auth

5:51 In code, g dot req dot auth holds who is calling : the API user, the row of a DB provider, what a token validator returned, and the claims of a single sign-on token. The same object in every language.

Root settings

6:06 The root user owns the settings of every token : from its dashboard, Deployment Settings, card Security, your APIs. The secret that signs every token, tokens accepted across admin accounts, the lifetime, the refresh, the issuer and the algorithm.

Best practices

6:24 Best practices. Hash passwords in the schema. Put a condition on every provider, so blocking is one update. Keep tokens short and refresh them. Put display data in the token, never secrets. A custom validator must check a signature, not only decode. And give roles with a groups column : that is the next video.

Recap

6:47 That was auth providers. A DB token generator over your own table. Hashed passwords, signed and refreshed tokens. An API that asks for a person with one setting. Your own sign-in code, and single sign-on. Next : roles, row ownership and best practices. API Maker. Build faster, spend smarter, deliver better.