Authentication (AuthN): determines identities, are you who you say you are (
401 Unauthorized, but actually "unauthenticated" instead of "unauthorized")
Authorization (AuthZ): determines permissions, if your identity is confirmed, do you have access to the resource. (
front channel: less secure channel, e.g. from browser to server
back channel: highly secure channel, e.g. from server to server
Sessions vs Tokens
- stateful: sessions using a cookie
- stateless: tokens using JWT/OAuth, etc
- user submit username/password
- server checks DB for verification
- server creates a session (sessions are stored server-side, i.e. stateful) and issues a cookie with a session ID
- user submit requests with the cookie
- server validates it against session store and grant access
- user logout or timeout, server destroy the session
Not store on server-side, but stored in client storage; server does not need to keep track of user sessions
- user submit username/password
- server checks DB for verification
- server generates a temporary token and sends back
- user stores token in client storage
- user sends token along with each request
- server verifies the token and grant access
localStorage: browser key-value store with JS API; has no expiration time; every site has its own, other sites cannot read/write; max size higher than cookie (5MB/domain vs 4KB/cookie); good for public, non-sensitive, string data
sessionStorage: gets cleared when page is closed
HTTP supports the use of several authentication mechanisms to control access to pages and other resources. These mechanisms are all based around the use of the
401 status code and the
WWW-Authenticate response header.
When you send a request without credentials:
GET /home HTTP/1.1 Host: ...
You will get a
401 Unauthorized response(though it is actually Unauthenticated instead of Unauthorized):
HTTP/1.1 401 Unauthorized WWW-Authenticate: Basic realm="..."
Now send the request WITH the credentials:
GET /home HTTP/1.1 Host: ... Authorization: Basic Zm9vOmJhcg==
You should get
Where the word "Basic" is just one of the authentication mechanisms.
Defined in RFC 1954.
- simplest technique for enforcing access controls
- doesn't require cookies, session identifiers, or login pages
- uses standard fields in the HTTP header, obviating the need for handshakes
<username>:<password>string encoded with Base64 in transit, but not encrypted or hashed in any way, should only be used with HTTPS
- has to be sent in the header of each HTTP request(the web browser needs to cache credentials)
- no "log out"
The client sends a hashed form of the password to the server. Although, the password cannot be captured over HTTP, it may be possible to replay requests using the hashed password.
This uses a secure challenge/response mechanism that prevents password capture or replay attacks over HTTP. However, the authentication is per connection and will only work with HTTP/1.1 persistent connections. For this reason, it may not work through all HTTP proxies and can introduce large numbers of network round trips if connections are regularly closed by the web server.
- not formalized by any RFC; not using the formal HTTP authentication techniques (basic or digest).
- use the standard HTML form fields to pass the username and password values to the server.
- the server validates the credentials, creates a session which will be passed between client and server in following communications.
- supports "log off", or the server logs the user off (e.g. due to inactivity) by invalidating the session key. This is the key difference comparing to basic auth.
- similar to basic auth, has to use with HTTPS
- Resource Server
- Auth Server
2 kinds of tokens:
- Access Token: short-lived(~1hr), grants client access to the Resource Server.
- Refresh Token: long-lived(duration of log-in), grants client the ability to get Access Token from Auth Server.
- Client redirects to Auth Server for user login with redirect URI (for callback) and scope
- After login and consent, Auth Server redirects to Client with Authorization Code back to Client (in front channel)
- Client use Authorization Code to get access token (via back channel, server to server)
- Client uses access token to talk to resource server
- Authorization code
- front + back channel
- for web app with server backend
- auth server returns authorization code in front channel, then client uses authorization code to get access code in back channel)
- Authorization code with PKCE
- for native mobile app
- uses random code instead of client secret
- front channel only
- for SPA with API backend, like pure React/Angular app
- auth server returns access token directly, instead of authorization code)
- Client credentials
- back channel only
- for microservices and APIs
- Resource owner password credentials
- back channel only
- not recommended for new apps
OAuth 3.0 is under development: oauth.xyz
OAuth is authorization only, NOT for authentication. Use OpenID Connect for authentication:
- will return an ID token, which is a JWT
JWT: JSON Web Token
Format: concatenate header, payload, and signature using comma(
- header: how the signature should be computed
- payload: the data being communicated
- signature: proves the source of data is authentic, signing
<header>.<payload>using a secret key.
Encoded vs Signed vs Encrypted:
- encoded: the 3 parts are url encoded so they can be used as part of url, however they are not encrypted
- signed tokens: can verify the integrity of the claims in the payload, however the claims can still be visible if without encryption
- encrypted: encrypted tokens hide the claims from other parties
Secret vs Public/Private keys:
- JWT can be signed using a secret, e.g. HMAC algorithm
- or by public/private key pair, e.g. RSA or ECDSA, in this case the signature certifies that the JWT is signed by the party holding the private key
json web token: https://jwt.io/
JWK vs JWS vs JWT vs JWE
- RFC 7515 - JSON Web Signature (JWS)
- RFC 7516 - JSON Web Encryption (JWE)
- RFC 7517 - JSON Web Key (JWK)
- RFC 7518 - JSON Web Algorithms (JWA)
- RFC 7519 - JSON Web Token (JWT)
JWT by default is not encrypted; JWE specifies how encryption should be done.
IAM: Identity and Access Management
Once the source of the data is verified (e.g. by JWT's signature), we can check IAM to see if the user (some user info like id may be inside JWT's payload) has the permission to the requested resources.
3 types of entities:
There are multiple identity related services even from the same cloud provider, and it can be confusing. One key difference is the target audience, take Google Cloud for example:
- Cloud IAM: to control Google Cloud resources, e.g. who can create a new VM
- Identity Platform/Firebase Auth: for end users, or GCP customers' customers
- BeyondCorp, Context-Aware Access: for IT admins to control employees access
The most popular IDaaS, a public company.
Google Identity Platform and Firebase Auth
Cloud API: API Key Or Not
API Key can be stolen in many ways(e.g. accidentally checked-in GitHub). Use API Key if you do not have a backend and talk to third-party services directly; otherwise use your backend to handle auth to cloud APIs.
kinit: talk to KDCkey distribution center=> kerberos use Authentication Server(AS) and Ticket Granting Server(TGS)
Ticket Granting Ticket (TGT)
Universal (Centralized) vs Embedded Login
Universal Login is preferred.
- Universal: login page is hosted on a different site, e.g. all Google login will be redirected to
accounts.google.com, after successfully login user will be redirected back.
- Embedded: the login form is embedded, the credentials will be sent to the backend or a different site for auth, in the latter case it will be cross-origin.
IdP: a trusted third party that authenticates users and provides them with a single set of credentials that can be used to access multiple applications.
Examples of IdPs that support OIDC include Google, Microsoft, and Amazon.
OpenID Connect is a flavor of OAuth2 supported by some OAuth2 providers. The protocol's main extension of OAuth2 is an additional field returned with the access token called an ID Token. This token is a JSON Web Token (JWT) with well known fields, such as a user's email, signed by the server.
OIDC IdP: e.g. cloud: Google; self-owned: dex, Keycloak, CloudFountry UAA, OpenUnison, etc.
Open source project from RedHat. RedHat uses Keycloack as the upstream project for their RH-SSO product.
Migrate to the new Quarkus distribution from the legacy WildFly distribution https://www.keycloak.org/migration/migrating-to-quarkus
SAML vs OIDC
- identity protocols that authenticate users, transmit data, and provide access control information and a communication method for a user's ID.
- enables single sign-on (SSO).
- an IdP can choose to implement either or both.
- both standards are highly secure and can be customized to improve user privacy by controlling which user attributes (called claims) are shared.
- both utilize a third-party identity provider to authenticate.
- XML-based protocol. Because SAML , a user can authenticate once and then access multiple applications without having to re-enter credentials.
- an older standard and more widely adopted in enterprises that use web-based applications.
- more complex than OIDC, more challenging to implement.
OpenID Connect (OIDC)
- an authentication layer built on top of the OAuth 2.0.
- allows third-party applications to obtain basic end-user profile information and verify an end user's identity.
- OpenID Connect (OIDC) allows a wide range of users to be identified, from single-page applications (SPAs) to native and mobile apps.
- newer and gaining traction with mobile and native applications.
- uses a public, third-party IdP to authenticate users
- simpler to implement because it outsources encryption to HTTPS or SSL, which is already integrated on both the client and server sides.
- relies on encoded JSON Web Tokens (JWTs), a lighter-weight solution that delivers better performance.
- lacks some high-security features that are needed by certain sectors, such as the banking industry.