-
Notifications
You must be signed in to change notification settings - Fork 2
Authentication
Learn how to do authentication
- AS - Authorization Server.
- Authentication - prove that you are who you claim to be.
- CIMD - Client ID Metadata Document.
- ID token - identificaiton token.
- JWT - Java Web Token.
- local token validation - offline method for token introspection
- only possible for JWT.
- M2M - Machine-to-machine.
- OAuth - Open Authentication.
- PKCE - Proof Key for Code Exchange.
- OAuth - Open Authentication.
- OIDC - OpenID Connect. Identity layer built on top of the OAuth 2.0 framework.
- Allows 3rd party apps to verify the id of the end-user and to obtain basic user profile information.
- Not for M2M TODO why does aws EKS use it then?
- Opeaque token - random string of characters, with no information in it.
- Requires serverside validation.
- PKCE - Proof Key for Code Exchange.
- Referesh token - for refreshing the token
- RO - Resource Owner.
- RS - Resource Server.
- SAML - Security Assertion Markup Language.
- SDLC - Software Development Life Cycle.
- SSO - Single Sign-on.
- Token introspection - verify token via the AS.
- Required for Opeaque token
- optional for JWT token.
- https://auth0.com/docs/get-started/onboarding/self-service-m2m
- The OAuth 2.0 Authorization Framework
- Proof Key for Code Exchange by OAuth Public Clients
- Minikube and OAuth2
- Installing an OAuth app in your personal account
- Setting up Google OAuth on Minikube
- Testing OIDC
- Kubernetes Authenticating
-
Authorization server(AS) - Responsible for authenticating the resource owner.
- Issues access tokens to the authorized client.
-
Client - application/entity that wants to access the resouerces.
- Requests access to the resources on behalf of the resource owner.
- e.g.
- Third-party application like SPA running in a browser(public client)
- Backend server or enterprise application(confidential client)
-
Resource owner(RO) - owner of the resources.
- Owns the data and resources that are being accessed.
- Grants or denies permission for data access.
-
Resource server(RS) - hosts the protected resources and data.
- Validates the access tokens before allowing access to resources.
-
how does the client know that it needs to ask for a token
-
How does the resource server verify the token?
- /authorize
- /introspect
- /userinfo
- /token - used to exchange authorization code for a token.
- opaque
- JWT
- Payload
- iss: Issuer
- sub: Subject
- aud: Audience
- exp: Expiration Time
- iat: Issued At
- jti: JWT ID
- azp: Authorized Party
- scope: Defines the permissions of the token.
- roles: A list of roles assined to the user.
- Signature
- Symetric signing - Sinle shared secret used for signing and verification
- Asymetric signing - pub/priv key.
- self validation
https://auth0.com/docs/get-started/auth0-overview/create-applications/native-apps
sequenceDiagram
ResourceServer->>AuthorizationServer : Register with AS.
Native apps should use the Authorization Code flow with PKCE for secure authentication.
sequenceDiagram
ResourceOwner->>Client : initiate task
Client->>AuthorizationServer: AuthRequest(ClientId)
AuthorizationServer->>ResourceOwner: Consent screen(client metadata)
ResourceOwner-->>AuthorizationServer : Approve
AuthorizationServer-->>Client : Authorization code
Client->>AuthorizationServer : exchange code
AuthorizationServer->>Client : Complete auth and redirect to redirect_url
Client->>AuthorizationServer : Request resource access token
AuthorizationServer-->>Client : resource access token
Implicit flow, deprecated for security issues.
sequenceDiagram
ResourceOwner->>Browser : login
Browser->>Client: ?
Client-->>Browser : URL-AS/authorize?
Browser->>AuthorizationServer : URL-AS/authorize? scope+state
AuthorizationServer->>Browser : authenticate and approve
Browser->>ResourceOwner : x
ResourceOwner-->>Browser : user+password + ack
Browser-->>AuthorizationServer : user+password + ack
AuthorizationServer->>AuthorizationServer: verify user+password
AuthorizationServer-->>Browser : redirect-url + accessToeken
Browser-->>Client : redirect-url + accessToken
Client->>ResourceServer : getResource + accessToken
ResourceServer->>AuthorizationServer : Introspection
AuthorizationServer-->ResourceServer : response
Introspection
-
Must be on the AS for opaque tokens.
-
for the JWT token it can be local or via the AS.
-
AuthRequest
- This could be e.g. login to google to gain access to dndbeyond.com
-
curl -X GET "URL-AS/authorize?client_id=<CLIENT_ID>&response_type=code&redirect_uri=&scope=orders:read&state="
- state - helps maintain state and prevent agains cfs? attacks
-
Set up connections
- the relationship between Auth0 and the identity provider is referred to as a connection
-
Create and register applications
- Client ID
- When you manually create an application, Auth0 assigns it a client ID, an alphanumeric string that serves as the application’s unique identifier.
- You will use this ID in your application code when you call Auth0 APIs.
- Client Secret.
- It must be kept confidential at all times. If anyone gains access to your application’s client secret, then they can impersonate your application and access protected resources.
- Manual CIMD Registration - seem to be a more secure method for registration.
- Identity verification - Domain ownership via HTTPS hosting
- best for - MCP clients, third-party integrations
- How CIMD works
- Client ID
- Login to github
- Click the icon in the top right corner
- Click Settings -> Developer Settings
- Click OAuth apps
- Click the button: New OAuth app
- Register a new OAuth app
- Application name:
- Homepage URL
- TODO used for what?
- Application description:
- Authorization callback URL:
- TODO is this where they are sent after the authorization is succesful?
- Enable Device Flow:
- Register a new OAuth app