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
  • github repo for Minikube-and-OAuth2
• Installing an OAuth app in your personal account
• Setting up Google OAuth on Minikube
• Testing OIDC
• Kubernetes Authenticating

OAuth roles

• 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?

TODO https://auth0.com/docs/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use

• /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

• Create a tenant

• 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

• 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: