Auth
-
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. (
403 Forbidden
) -
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.
Sessions
- 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
Tokens
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
Client Storage
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 Authentication
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 200 OK
Where the word "Basic" is just one of the authentication mechanisms.
Defined in RFC 1954.
Basic
- 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"
Digest
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.
NTLM
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.
Form-based Authentication
- 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
OAuth 2.0
3 roles:
- Client
- 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.
Example Flow:
- 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
Flows:
- 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
- Implicit
- 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
OpenID Connect (OIDC)
OpenID Connect is a flavor of OAuth2 supported by some OAuth2 providers, notably Microsoft Entra ID, Salesforce, and Google.
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.
To identify the user, the authenticator uses the id_token
(not the access_token
) from the OAuth2 token response as a bearer token.
OAuth is authorization only, NOT for authentication. Use OpenID Connect for authentication:
- set
scope=openid
in request - will return an ID token, which is a JWT
JWT: JSON Web Token
Format: concatenate header, payload, and signature using comma(,
)
<header>.<payload>.<signature>
- 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:
- Resources
- Permissions
- Roles
Identity-as-a-Service (IDaaS)
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
Okta
The most popular IDaaS, a public company.
Auth0
auth0 architecture: http://highscalability.com/blog/2018/8/27/auth0-architecture-running-in-multiple-cloud-providers-and-r.html
Google Identity Platform and Firebase Auth
https://cloud.google.com/identity-platform/docs/product-comparison
https://firebase.google.com/docs/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.
Kerberos
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 vs IAM
- IdP: "identity provider", to manage users and groups. Some public clouds provide the Identity-as-a-Service (IDaaS) solution.
- IAM: to manage policies and to apply permissions / roles to those users and groups. Can use an external identity provider (IdP).
IdP
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.
OIDC
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.
Keycloack
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
Both:
- 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.
SAML:
- 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.
ZERO TRUST NETWORK ACCESS
Based on the principle that no user or device inside or outside of a network can be trusted by default.
Zero Trust vs VPN: full access once connected to the VPN.
BeyondCorp is Google's implementation of the zero trust model.
By shifting access controls from the network perimeter to individual users, BeyondCorp enables secure work from virtually any location without the need for a traditional VPN.
Security token service (STS)
A cross-platform open standard. For issuing user credentials with limited lifespan AND limited privileges.
A Security Token Service (STS) is a third-party web service that can issue JSON Web Tokens (JWTs) to client applications.