API authentication with access tokens from OAuth 2.1
API authentication is how your API decides which caller sent a request and what that caller is allowed to do. The usual way to do it is to have callers present a short-lived access token issued over OpenID Connect and OAuth 2.1, and to have your API validate that token on every request. The Skycloak Platform is built to be the server that issues those tokens, so your API only has to check them.
How access tokens protect your API
An access token is a signed statement from your sign-in server that says who it was issued to, which API it is meant for and until when it is valid. Your web app, mobile app or another service gets one through an OAuth 2.1 flow: the authorization code flow when a person signs in, or the client credentials grant when one of your services calls another without a user. OAuth 2.1 requires PKCE (proof key for code exchange) on the authorization code flow, which stops a stolen authorization code from being exchanged for a token by someone else. The caller then sends the token in the Authorization header of each request to your API.
Access tokens are usually JSON Web Tokens, or JWTs, which means your API can check them locally without calling the sign-in server on every request. They expire after minutes rather than months, so a leaked token stops working soon, and a refresh token lets the client get a new one without asking the user to sign in again. Scopes in the token say what the caller may do, for example read invoices but not delete them, so your API can refuse an action the token was never granted. This keeps the decision about who may call what in one place instead of spreading it across your endpoints.
What your API checks on every request
Validating a JWT comes down to four checks on the token itself, followed by a check of its scopes, and skipping any of them leaves a gap. Your API checks the signature against the public keys your sign-in server publishes, so a token nobody signed is rejected. It checks that the issuer is your tenant's sign-in address and that the audience is your API, so a token minted for another application or another tenant is not accepted. It then checks the expiry time, and finally that the scopes cover the action being requested.
Each tenant on the Platform has its own sign-in address and its own signing keys, so your production API never accepts a token issued by your staging tenant. Standard JWT libraries in most languages can fetch the published keys, cache them and pick up new ones when the keys rotate, so you write very little of this code yourself. Sender-constrained tokens add one more protection. With DPoP (demonstrating proof of possession), planned for the Platform's first release, the client proves with its own private key that it holds the token, so a token copied out of a log or a proxy cannot be used by whoever copied it.
How access tokens differ from static API keys
A static API key is a long-lived secret that a caller sends with each request, and your API looks it up to decide who is calling. Keys are simple to hand out, but they usually never expire, they say nothing about the user behind the request, and a leaked key keeps working until someone notices and revokes it. Every check also needs a lookup in your own database, and rotating a key means coordinating with whoever holds it.
Access tokens avoid most of this because they expire quickly, name the application and, when there is one, the user, and carry scopes your API can enforce without a lookup. API keys still have a place for simple integrations, and the Platform's own management API uses keys with read and write scopes per resource. For your product's API, the Platform is built to issue the tokens over OpenID Connect and OAuth 2.1 so your team does not run that server, and a demo shows which of these pieces you can use today.
Frequently asked questions
Do I need a user to get an access token?
No. The client credentials grant lets one of your services authenticate as itself and get a token for calling another service, with no user involved. It is standard OAuth, and the token carries the calling service's identity and scopes instead of a user's.
Can my API check tokens without calling the Platform on each request?
Yes. The Platform is built to issue access tokens as signed JWTs, so your API can verify the signature with the public keys your tenant publishes and check the issuer, audience and expiry locally. It only needs to fetch the keys again when they rotate.
See the Skycloak Platform for yourself
Book a demo and we will walk you through the Platform with your own sign-in flows in mind.