Please enable JavaScript.
Coggle requires JavaScript to display documents.
Web Application Security - Coggle Diagram
Web Application Security
HTTPS
-
-
When a client connects to a server, it goes through a process of asymmetric encryption to agree upon a shared secret (handshake) after which all traffic is encrypted using the shared key
-
Token Based Validation
After user logs in and is validated, the server generates a secure, signed token and sends it back to client
-
-
-
Types of tokens
Access Tokens - grants access to protected resources, expires
Refresh Tokens - used to obtain a new access token after one has expired. Has a longer expiration time
OAuth 2
Protocol for authorization. Allows a client App to retrieve information from another system using a token that is valid for a limited amount of time. Meant only for authorization and not authentication. No standard way to return userinfo back for authentication
Terminology
-
-
-
Authorization Server - an auth server on iCloud that authenticates me as well as BrushStroke (via Client ID/Secret)
-
Authorization Grant - credential representing my permission to BrushStroke to access my picture and will be used by BrushStroke to get access token,
Authorization Code - Auth Grant sent with Auth Code to get auth server in iCloud by BrushStroke to get access token
Access Token - creds to access my photos. String representing specific scopes and durations and is enforced by iCloud resource and auth servers
Scope - permissions of a token. In my case, just photos and not files etc
Grant Types
Auth Code Grant Type - Extra step where code is first returned and then used to retrieve Token. E.g. integration with WePay.
- Auth Request - Client (browser) sends auth request and includes cient_id, redirect_uri, scope and state (to prevent CSRF)
- Auth Response - server redirects with code and state
- Token Request - Server-side post call with grant_type (authorizaton_code), code, client_id, client_secret
- Token response - returns access token, token type (bearer/jwt), refresh token, scope, expiration
Implicit Grant Type - Single Page JavaScript apps with no backend. Not secure (Eg Kliken)
- Auth Request - Client (browser) sends auth request and includes client_id, redirect_uri, scope and state (to prevent CSRF
- Auth Response - redirects to client URI with access token as a fragment of the auth url.
Client Credentials Grant Service to Service auth
- Token request - grant_type (client_credentials), client_id, client_secret, scope
- Token response - access_token, refresh_token, scope
Resource Owner Credentials Grant - used when resource owner trusts the client and is ready to share credentials. Insecure! Used to migrate existing users of HTTP basic or digest authentication to OAuth by converting creds to token.
- Token Request - Post request with response_type (password), client_id, client_secret, username, password, scope
- Token Response - access token
JSON Web Token (JWT)
Standard that defines safe, compact and self-contained way of exchanging information between client and server in the form of JSON. Cand be signed and encrypted
-
JWT Structure
-
Header - JSON that specifies the algorithm (alg) used to sign or encrypt the JWT and the "typ" content that is being signed and encrypted. Header also supports "kid" Key id parameter that identifies key. Useful when keys are rotated.
Can also include "jwk" parameter which is the son format of public key or "jku" which is URL of location where keys are stored
Payload: Main information that server uses to identify user and permissions. Permissions consists of claims. Three types of claims:
Registered Claim Names: Reserved and such as "iss", "sub", "exp" etc
Public Claim Names: Can be defined at will but should avoid collisions
Private Claim Names: Agreed by Producer and Consumer and can be subject to collision
Signature: Created by combining the header and payload and hashing them using the algorithm and a secret key
Validation
Signing can be Symmetric when only one server signs and validates the token. Asymmetric in distributed scenarios. Signing server uses private key, validating servers use public key
When server receives token, gets header and payload, decodes them and then signs them using the secret/public key and compares them to signature. If they match they are valid.
Also need to look at expiration claim, audience claim, not before claim etc
OpenId Connect
Terminologies
-
Identity Token - ID token has user information in JSON wrapped into a JWT token. It is meant for use by the client unlike the access token which is meant to be used by the resource server
-
Scope - information about the user. E,g, email, phone, profile, address
-
-
-
Endpoints
- Authorization endpoint - returns auth code after user authentication
- Token endpoint - exchange auth code for auth token and identity token
- Userinfo endpoint - request user profile information that was previously granted access to
Flows
Authorization Code Flow for Authentication
Similar to auth code flow for OAuth but scope must contain openid as one of values. If openid not passed, identity token not returned by the token endpoint. This becomes regular OAuth flow
Implicit Code Flow for Authentication
Used for single page JS apps. response_type = token, returns just token even if scope has openid.
response_type=id_token returns the token and not access token, scope is still openid
response_type = "token id_token" returns access token and identity token
A thin layer above OAuth that allows for authentication. Instead of an org storing user creds, can rely on an Identify Provider (like Google) to authenticate a user,