Vejju: August 2024

Key words

Knowledge Factor

Possession Factor

Inherence Factor

All individual factors are not secure, because if any factor comprimise.

So, we got 2FA or MFA came into picture.

SSO

Oauth

JWT (JSon Web Token) ==> not authentication, it's an authorization.

Okta

OpenConnectID

SAML (Secure Assertion Markup Language)

Azure Active Directory

Service Provider

IdentityProvider

Eg: AccessToken --> Employee ID card ( Authorization), validatity( lost or reported, left the orginations, Expire)

Session or Cookie Based Authorization

In Cookie, will maintain SESSION_ID

Load balance will maintain the session log in sticky Session pattern ( Scalability problem)

Here also, we have a problem if the shared session cache pattern is corrupted then it's single point failure

User is responsible to bring all security information for all microservices, so nothing but JWT

For Stateless server, will pass JWT

OAuth:

Service to service authorization

ResourceOwner

ResourceServer

AuthorizationServer

Client

with in same with diff microservices.

OpenIDConnect

Its a specification

Micro Service 12 Factor

The Twelve-Factor App is a methodology for building software-as-a-service apps

Codebase: One codebase tracked in version control, many deploys. A single codebase is shared across all environments, but there may be multiple deployments (e.g., staging, production).
Dependencies: Explicitly declare and isolate dependencies. Applications should not rely on implicit dependencies and should use dependency management tools to declare all dependencies explicitly.
Config: Store config in the environment. Configuration that varies between deploys (such as database credentials) should be stored in environment variables.
Backing Services: Treat backing services as attached resources. Resources like databases, messaging systems, and caches should be attached and detached from deploys without changing the app’s code.
Build, Release, Run: Strictly separate build and run stages. A codebase goes through a build stage to produce a release, which is then run in execution environments.
Processes: Execute the app as one or more stateless processes. Stateless and share-nothing processes ensure the app can scale out by adding more processes.
Port Binding: Export services via port binding. The application should be self-contained and expose services by binding to a port, rather than depending on the runtime environment to provide network services.
Concurrency: Scale out via the process model. The app can handle various workloads by running multiple processes.
Disposability: Maximize robustness with fast startup and graceful shutdown. Processes should start quickly and shut down gracefully to enable rapid deployment and scaling.
Dev/Prod Parity: Keep development, staging, and production as similar as possible. This minimizes the chances of bugs being environment specific.
Logs: Treat logs as event streams. Applications should not manage log files but should send their log output to the environment's centralized log management system.
Admin Processes: Run admin/management tasks as one-off processes. Administrative tasks, like database migrations, should be run in an isolated environment identical to the application’s execution environment.