In the heart of Kiryat Gat, a small city in the Southern District of Israel, a mother's prayers were answered. After a harrowing ordeal, Margalit Magadish finally held her daughter, Ory, in her arms again.

A Mother’s Gratitude, A Nation’s Hope: Israeli Soldier’s Release from Hamas Captivity

Republican mayoral candidate and current Fort Wayne city councilman Tom Didier announced a major change he would make to the Fort Wayne Police Department if he’s elected as mayor next week.    At a Monday press conference,

Didier announces he’ll promote Deputy Chief Mitch McKinney as new chief of police if he’s elected mayor

Robert Card, a man who reportedly claimed to hear voices, besides being obsessed with guns, was allowed to purchase an assault rifle. How is that possible?

We are no right to moralize

The Texas Rangers followed up their dramatic Game 1 victory with a flat performance in Game 2 as the lineup went limp and pitching left something to be desired.

3 Texas Rangers most to blame for Game 2 loss in the World Series

Lennox Lewis insisted he had the tools to defeat Tyson Fury in his fighting prime; Follow Mail Sport's coverage as Fury takes on former UFC star Francis Ngannou; LISTEN: Exclusive

Lennox Lewis insists he would've beaten Tyson Fury in his prime

Hear Rossini's "Le comte Ory" with a libretto by Eugène Scribe and Charles-Gaspard Delestre-Poirson on Classical IPR on Saturday at 1 p.m. This production is being presented by Opera Southwest and was performed at the National Hispanic Cultural Center, Albuquerque, NM under the baton of Anthony Barrese.

Opera Southwest: Le comte Ory

NORMANDY PARK, Wash. — A woman was forced into a car at gunpoint and then sexually assaulted in Normandy Park on Monday.

Woman walking dog forced into car at gunpoint, sexually assaulted in Normandy Park

More than 30 volunteers this week gleaned leftover vegetables from the Ron Ory Community Garden Plots for donation to Loaves and Fishes Community Services. About 1,365 pounds of produce was donated to the local food pantry, closing out this year’s gardening season, Naperville Park District officials said in a news release.

Garden plot volunteers donate record produce amount

AMANDA JO HESS: Istrouma Brewing, St. Gabriel, 5:30 p.m. KIRK HOLDER: Galvez Seafood, Prairieville, 5:30 p.m. BRYAN SOUTHWICK: Mike Anderson's, Gonzales, 6 p.m ...

Sonny Landreth, The Molly Ringwalds, Ben Bell and 139 other musical shows this week

Air Caraïbes returned to Santo Domingo, offering up to 6,000 weekly seats in 3 classes. The airline arrived at the International Airport of the Americas (AILA) with the A350-900 aircraft on its inaugural flight.

Air Caraïbes returns to Santo Domingo with twice-weekly flights from Paris

Ory Hydra is a popular open-source OAuth2 and OpenID Connect that provides secure authentication and authorization for applications. One of the key challenges in building a scalable and performant OAuth2 server is managing the persistence layer, which involves storing and retrieving data from a database. server Motivation Ory was approached by a popular service provider to optimize performance in their auth system at high load. They often struggled to cope with the huge influx of authorization grants during peak times (over 600logins/sec). Looking for another solution, they started to evaluate Ory Hydra, investigating if it can handle this amount of grants. After reaching out to the team, we started to investigate ways to improve the overall performance to make Ory Hydra faster and more scalable than ever before. The key to success was to re-engineer parts of Hydra's persistence layer to reduce write traffic to the database, moving to a transient OAuth2 flow. Moving to a transient OAuth2 flow One of the core parts of this work was moving a large chunk of the transient OAuth2 flow state, which is exchanged between the three parties involved in an OAuth2 flow, from the server to the client. Instead of persisting transient state to the database, the state is now passed between the parties as either AEAD-encoded cookies or AEAD-encoded query parameters in redirect URLs. AEAD stands for authenticated encryption with associated data, which means that the data is confidential and also can't be tampered with without knowing a secret (symmetric) key. The flow is then only persisted in the database once when the final consent is given. This change has several benefits. First, it reduces the amount of data that needs to be stored in the database, which in turn reduces write traffic. Second, it eliminates the need for multiple indices on the flow table that were previously used during the exchange. The OAuth2 authorization code grant flow in detail The relevant part of the OAuth2 flow that we wanted to optimize is an exchange between the client (acting on behalf of a user), Hydra (Ory's OAuth2 Authorization Server), and the login and consent screens. When a client requests an authorization code through the , the user will be redirected first to the login UI to authenticate and then to the consent UI to grant access to the user's data (such as the email address or profile information). Authorization Code Grant Below is a sequence diagram of the exchange. Observe that each UI gets a as part of the URL parameters (steps 3 and 12) and then uses this as a parameter to retrieve more information (steps 4 and 13). Finally, both UIs either accept or reject the user request, usually based on user interaction with the UI (from steps 6 to 8 and 15 to 17). This API contract keeps Ory Hydra headless and decoupled from custom UIs. CHALLENGE CHALLENGE Optimization: Passing the AEAD-encoded flow in the URL parameters To reduce database access we now pass as the , , , and an AEAD-encoded flow. This way, we rely on the parties involved in the OAuth2 flow to pass the relevant state along. LOGIN_CHALLENGE LOGIN_VERIFIER CONSENT_CHALLENGE CONSENT_VERIFIER Before After The login and consent challenges and verifiers are random UUIDs stored in the database. The login and consent challenges and verifiers are the AEAD-encoded flow. Accepting or rejecting a request from the UI involves a database lookup for the specific challenge. Accepting or rejecting a request from the UI involves decrypting the flow in the challenge and generating an updated flow as part of the verifier. Implementation Since Ory Hydra is open source, you can review code changes in the Ory GitHub repositories. This is the relevant . commit Here is where we encode the flow in the specific challenges and verifiers: // ToLoginChallenge converts the flow into a login challenge.
func (f *Flow) ToLoginChallenge(ctx context.Context, cipherProvider CipherProvider) (string, error) {
    return flowctx.Encode(ctx, cipherProvider.FlowCipher(), f, flowctx.AsLoginChallenge)
}

// ToLoginVerifier converts the flow into a login verifier.
func (f *Flow) ToLoginVerifier(ctx context.Context, cipherProvider CipherProvider) (string, error) {
    return flowctx.Encode(ctx, cipherProvider.FlowCipher(), f, flowctx.AsLoginVerifier)
}

// ToConsentChallenge converts the flow into a consent challenge.
func (f *Flow) ToConsentChallenge(ctx context.Context, cipherProvider CipherProvider) (string, error) {
    return flowctx.Encode(ctx, cipherProvider.FlowCipher(), f, flowctx.AsConsentChallenge)
}

// ToConsentVerifier converts the flow into a consent verifier.
func (f *Flow) ToConsentVerifier(ctx context.Context, cipherProvider CipherProvider) (string, error) {
    return flowctx.Encode(ctx, cipherProvider.FlowCipher(), f, flowctx.AsConsentVerifier)
} In the persister (our database repository) we then decode the flow contained in the challenge. For example, here's the code for handling a consent challenge: func (p *Persister) GetFlowByConsentChallenge(ctx context.Context, challenge string) (*flow.Flow, error) {
    ctx, span := p.r.Tracer(ctx).Tracer().Start(ctx, "persistence.sql.GetFlowByConsentChallenge")
    defer span.End()

    // challenge contains the flow.
    f, err := flowctx.Decode[flow.Flow](ctx, p.r.FlowCipher(), challenge, flowctx.AsConsentChallenge)
    if err != nil {
        return nil, errorsx.WithStack(x.ErrNotFound)
    }
    if f.NID != p.NetworkID(ctx) {
        return nil, errorsx.WithStack(x.ErrNotFound)
    }
    if f.RequestedAt.Add(p.config.ConsentRequestMaxAge(ctx)).Before(time.Now()) {
        return nil, errorsx.WithStack(fosite.ErrRequestUnauthorized.WithHint("The consent request has expired, please try again."))
    }

    return f, nil
} Let's look at the impact of the changes when compared to the code without optimizations: The flows are now much faster and talk less to the database. Improved indices lead to further performance improvements By introducing a new index on the table, we were able to increase throughput and decrease CPU usage on PostgreSQL. The screenshot below shows the execution of the benchmarks without the improved indices where CPU usage spikes to 100%, and with improved indices, where CPU usage stays below 10%. hydra_oauth2_flow With the newly added indices, CPU usage (green bars) is removed, which reduces the likelihood of BufferLocks and related issues: Results The code and database changes reduced the total roundtrips to the database by 4-5x (depending on the amount of caching done) and reduced database writes by about 50%. Benchmarks Benchmarking the new implementation on Microsoft Azure with the following specifications: Services Configuration Total max SQL connections Notes Ory Hydra Consent App OAuth2 Client App rakyll/hey (http benchmark tool) 3x Standard_D32as_v4; South Central US 5x Standard_D8s_v3; South Central US 512 Every VM ran all the processes mentioned. PostgreSQL 14 in HA configuration Memory Optimized, E64ds_v4, 64 vCores, 432 GiB RAM, 32767 GiB storage; South Central US RAM beats CPU. Ory can perform up to at the peak and in the above configuration. This is possible by making the flow stateless and optimizing indices in frequently used queries. 1090 logins per second 800 logins / second consistently Conclusion The performance optimization work done by the Ory team has resulted in a significant improvement in Hydra's performance and scalability. By reducing write traffic to the database and improving the codebase and dependencies, Hydra is now faster and more responsive than ever before. By improving the indices, Hydra now scales much more efficiently with the number of instances. In the future, we will continue to optimize Ory's software to handle even more traffic. We believe that it's possible to get 5x more throughput on a single PostgreSQL node with data model optimizations. If you're building an OAuth2 server, we highly recommend giving Ory's fully certified OpenID Connect and OAuth2 implementations a try: Ory OAuth2 – our running on the global Ory Network, based on Ory Hydra – already utilizes the optimizations described in this article and setting it up only takes few minutes! fully managed service open source Also published . here

Scaling Ory Hydra to Two Billion Monthly OAuth2 Flows on a Single PostgreSQL DB

Escalamiento de Ory Hydra a dos mil millones de flujos mensuales de OAuth2 en una única base de datos de PostgreSQL

Mise à l'échelle d'Ory Hydra à deux milliards de flux OAuth2 mensuels sur une seule base de données PostgreSQL

सिंगल पोस्टग्रेएसक्यूएल डीबी पर ओरी हाइड्रा को दो बिलियन मासिक OAuth2 फ्लो तक स्केल करना

Ory Hydra を単一の PostgreSQL DB で月間 20 億の OAuth2 フローに拡張

Dimensionando o Ory Hydra para dois bilhões de fluxos OAuth2 mensais em um único banco de dados PostgreSQL

Mở rộng quy mô Ory Hydra lên hai tỷ luồng OAuth2 hàng tháng trên một cơ sở dữ liệu PostgreSQL

在单个 PostgreSQL 数据库上将 Ory Hydra 扩展到每月 20 亿个 OAuth2 流量

Building a user management solution using ORY Oathkeeper and Auth0 What are we doing? I’m part of a team-building platform that requires login and user management functions. We’re using a combination of Auth0, widely used for user management, and ORY Oathkeeper, an open-source solution. The combination of Oathkeeper and Auth0 is not a common use case, but it’s an elegant configuration-driven setup. It enables us to decouple our business logic from our user sign-in logic. That’s beneficial for microservice architecture scenarios — as our application scales, we can reuse our user authentication logic across all our services. Moving away from monolith login features We started out with a single service that handles the register, login, authentication, authorization, routing, and business logic. As the application and needs grow, we want to add more features and move our services to a more micro-service-friendly setup. We also want to decouple the business logic from the user authentication. From the application developer's point of view, it’s also a clean and easy-to-use solution, as it puts all the auth responsibility on Oathkeeper. The application doesn’t need to verify any credentials, it just receives a header added by the proxy. If it exists, the user is logged in. If it doesn’t, they are not. Using existing solutions Using existing tools can give us feature-rich solutions that have been vetted in production and refined over time. Often we don’t realize how many components are in a seemingly simple feature such as login and logout until we start scoping out requirements or even building it. For example, for user-management and surrounding features, you need CSRF protection, password hashing, email verification, securely storing user credentials, social sign-in, token signing, security compliance, and the list goes on. Requirements for auth solution Stateless API and session store A solution to keep our backend services all stateless, and keep the user session state outside of the application logic. Login Users logging into the application would get a signed JWT token and return to the frontend, saved in a cookie (or localStorage) and passed upstream. Ongoing requests Once a user is logged in, the frontend application passes down the token via header/cookie on every subsequent request, then upstream services would verify and authenticate the request using the JWT token passed along with the requests. User management Our tool of choice was . It’s not open-source software, but there are a plethora of features and great tooling for it. Auth0 is “user-management as a service” software. It has wild adoption and great community support and resources, providing us with many features, such as: Auth0 Login and sign-up interface and functionality Login via OIDC-compatible social login via OAuth2 Login via username and password Email verification and password resets OpenID compliant support with token signing Upon sign in we get a JWT token from Auth0 with customizable expiry and metadata Built in security compliance link And much more (web GUI to handle users, webhooks, analytics, user roles, multi-factor authentication, etc.) Oathkeeper Oathkeeper is a proxy that supports many authentication and authorization features. It has many features to support sessions and allow us to authenticate, mutate, and route requests before reaching the business logic: Configuration driven proxy Authenticators (JWT support, fetching cookies from another service, oauth2 introspection) Authorizers (route-based, or remote service-based access-control rules) Mutators (setting headers or cookies based on session info, or updating the session with a remote service) Error handling Routing (proxying requests to microservices) Native Kubernetes support through their controller and custom resources High-level setup overview A brief explanation of the setup from the ground up: Cloud Infrastructure on Kubernetes Ingress Routing proxy (Oathkeeper allows requests to be routed to the authentication endpoints while safeguarding the rest of the endpoints, keeping the request on the same domain to make cookie management and CORS easier) Auth0 (user-identity service and storage) Session handling(Oathkeeper uses to manage and verify the sessions) JWT authenticator Auth endpoints to handle token exchange Backend application Frontend application Topology of the setup is as follows: Login Flow and Request flow Setting up Auth0 In our case, we have configured Auth0 following the . While submitting the authorization request, we must include the scope . Then Auth0 will return an ID token when obtaining userInfo, which in this example is the user’s token. This way we don’t need to maintain, rotate or deploy a set of private or public keys, implement code to sign or verify JWT tokens, or figure out how to secure user credentials or sessions in your database. regular web app flow openId Proxy (Oathkeeper) setup In the proxy we need to set up three parts: Routing Here we want to split up the authenticated routes, and routes to Login via `Rules` in Oathkeeper. The Oathkeeper controller (oathkeeper-maester) will pick up `Rules` applied to kubernetes then apply it to Oathkeeper’s config automatically. Session creation (JWT authenticator) Conveniently, Oathkeeper has a suite of plugins to handle common authentication methods. We’re using the id_token from Auth0 as the token and verifying it using the , configuring the JWT plugin as follows: JWT authenticator Request mutation Oathkeeper also provides other middleware, such as mutation plugins, which can access the session data and then inject metadata into the request downstream. In this case, we want to remove authentication from the application logic while keeping the authorization and user lookup in the application, so we can pass the user-id and email to the application. This means that by the time the request gets to the application, it can check for the existence of the X-User-Id header. If it exists, the specified user is logged in. If a user isn’t logged in, the request won’t even reach the application. Deployment We’re deploying Oathkeeper onto our infrastructure using via , but you can also deploy it via normal kubernetes manifest files. Helm charts Terraform Where `files/oathkeeper-values yml` will follow . . this template Auth service You will need to implement a few endpoints to handle the interactions with Auth0. Note that you can also implement these in your backend application and route them to the same place, but for clarity the logic is represented as its own service: Login [ ] docs Exchange token [ ] docs Logout [ ] docs Upon success, all three of these methods will redirect the user back to your frontend application. Backend service To let the frontend determine whether a user is logged in or not, we can implement an endpoint like /whoami that checks the headers injected by Oathkeeper and returns the user info. Then you can create stateless API calls that check the user’s logged-in status on the frontend and leverage Auth0 as your logged-in state controller. Here’s an example in node.js. You could have a middleware to look up the user, such as: Frontend Login: To log in, you can simply redirect the user to the `<ingress>/auth0/login` and it will redirect you to the Auth0 login page, then bring you back to your application with the cookie set. Check user status: With the endpoint in the backend implemented, in the frontend, you can easily have a function as follows to determine if a user is signed in. Conclusion Oathkeeper is a useful open-source tool that can be integrated with Auth0 to create an elegant solution for decoupling user authentication and application logic. This approach allows you to quickly build additional services sharing the user authentication setup. Consider this method when building your next application! David Cheung is an Engineering Partner at Commit. He has been in software development for over a decade honing his expertise in full-stack development, and is passionate about open source projects. Also Published Here

How to Build a User Management Solution with ORY Oathkeeper and Auth0

Microservice architecture is nowadays almost a standard for backend development. An API gateway is an excellent way to connect a group of microservices to a single API accessible to users. API gateways are available from cloud providers such as AWS/Azure/Google Cloud Platform and Cloudflare. Kong is a scalable API gateway built on open source and can be an excellent alternative if you don't want to have your system locked into a particular vendor. This tutorial shows an example using Kong API gateway, , and . The illustration below shows you the final architecture we are going to build in this guide Ory Kratos Ory Oathkeeper The full source code for this tutorial is available on github What we will use gateway can be an excellent solution for an ingress load balancer and API gateway if you do not want vendor lock-in of any cloud API Gateways in your application. Kong uses and Lua. OpenResty extends Nginx with Lua scripting to use Nginx's event model for non-blocking I/O with HTTP clients and remote backends like PostgreSQL, Memcached, and Redis. OpenResty is not an Nginx fork, and Kong is not an Openresty fork. Kong uses OpenResty to enable . Kong OpenResty API gateway features acts like an identity and access proxy for our microservices. It allows us to proxy only authenticated requests to our microservices, so we don't need to implement middleware to check authentication. It can also transform requests, for example, convert session auth into JWT for a back-end service. Oathkeeper is the authentication provider; it handles all first-party authentication flows: username/password, forgot password, MFA/2FA, . It also provides OIDC/social login capabilities for example, "Login with GitHub". Kratos and more Building simple microservices Let's say we have two microservices: and . They are pretty simple and serve only to test our API gateway, but you can switch them out for more complex components. hello world The "World" microservice exposes a API endpoint and returns a simple JSON message: /world package main

import (
	"encoding/json"
	"log"
	"net/http"
)

type Response struct {
	Message string `json:"message"`
}

func helloJSON(w http.ResponseWriter, r *http.Request) {
	response := Response{Message: "World microservice"}
	w.Header().Set("Content-type", "application/json")
	w.WriteHeader(http.StatusOK)
	json.NewEncoder(w).Encode(response)
}
func main() {
	http.HandleFunc("/world", helloJSON)
	log.Fatal(http.ListenAndServe(":8090", nil))

} The "Hello" microservice exposes a API endpoint and returns a simple JSON message: /hello package main

import (
	"encoding/json"
	"log"
	"net/http"
)

type Response struct {
	Message string `json:"message"`
}

func helloJSON(w http.ResponseWriter, r *http.Request) {
	response := Response{Message: "Hello microservice"}
	w.Header().Set("Content-type", "application/json")
	w.WriteHeader(http.StatusOK)
	json.NewEncoder(w).Encode(response)
}
func main() {
	http.HandleFunc("/hello", helloJSON)
	log.Fatal(http.ListenAndServe(":8090", nil))

} We now want to secure access to these microservices and let only authenticated users access these endpoints. Okay. Let's start hacking, shall we? Ory Kratos setup Follow the guide to set up Ory Kratos. In this tutorial, you only need a docker-compose file with the following configuration: Quickstart postgres-kratos:
    image: postgres:9.6
    ports:
      - "5432:5432"
    environment:
      - POSTGRES_USER=kratos
      - POSTGRES_PASSWORD=secret
      - POSTGRES_DB=kratos
    networks:
      - intranet

  kratos-migrate:
    image: oryd/kratos:v0.8.0-alpha.3
    links:
      - postgres-kratos:postgres-kratos
    environment:
      - DSN=postgres://kratos:secret@postgres-kratos:5432/kratos?sslmode=disable&max_conns=20&max_idle_conns=4
    networks:
      - intranet
    volumes:
      - type: bind
        source: ./kratos
        target: /etc/config/kratos
    command: -c /etc/config/kratos/kratos.yml migrate sql -e --yes

  kratos:
    image: oryd/kratos:v0.8.0-alpha.3
    links:
      - postgres-kratos:postgres-kratos
    environment:
      - DSN=postgres://kratos:secret@postgres-kratos:5432/kratos?sslmode=disable&max_conns=20&max_idle_conns=4
    ports:
      - '4433:4433'
      - '4434:4434'
    volumes:
      - type: bind
        source: ./kratos
        target: /etc/config/kratos
    networks:
      - intranet
    command: serve -c /etc/config/kratos/kratos.yml --dev --watch-courier

  kratos-selfservice-ui-node:
    image: oryd/kratos-selfservice-ui-node:v0.8.0-alpha.3
    environment:
      - KRATOS_PUBLIC_URL=http://kratos:4433/
      - KRATOS_BROWSER_URL=http://127.0.0.1:4433/
    networks:
      - intranet
    ports:
      - "4455:3000"
    restart: on-failure


  mailslurper:
    image: oryd/mailslurper:latest-smtps
    ports:
      - '4436:4436'
      - '4437:4437'
    networks:
      - intranet Some notes on the network architecture: HTTP and are the public and admin API's of Ory Kratos. :4433 :4434 HTTP for Mailslurper - a mock Email server. You can get an activation link by accessing . :4436 http://127.0.0.1:4436 HTTP for the UI interface that allows one to start sign-up/login/recovery flows. :4455 After running you can open to test your configuration. docker-compose up http://127.0.0.1:4455/welcome Configuring Ory Oathkeeper Now we can start configuring our gateways for this example. Kong is the entry point for the network traffic. Ory Oathkeeper would be accessible from the internal network only in this case. Let's review our architecture diagram from before: Oathkeeper checks sessions and proxies traffic to our microservice while Kong provides ingress load balancing. We can even set up to have a more robust configuration for our service. Here is how we configure the access rules for Ory Oathkeeper: Round-Robin DNS -
  id: "api:hello-protected"
  upstream:
    preserve_host: true
    url: "http://hello:8090"
  match:
    url: "http://oathkeeper:4455/hello"
    methods:
      - GET
  authenticators:
    -
      handler: cookie_session
  mutators:
    - handler: noop
  authorizer:
    handler: allow
  errors:
    - handler: redirect
      config:
        to: http://127.0.0.1:4455/login
-
  id: "api:world-protected"
  upstream:
    preserve_host: true
    url: "http://world:8090"
  match:
    url: "http://oathkeeper:4455/world"
    methods:
      - GET
  authenticators:
    -
      handler: cookie_session
  mutators:
    - handler: noop
  authorizer:
    handler: allow
  errors:
    - handler: redirect
      config:
        to: http://127.0.0.1:4455/login The Ory Oathkeeper configuration: log:
  level: debug
  format: json

serve:
  proxy:
    cors:
      enabled: true
      allowed_origins:
        - "*"
      allowed_methods:
        - POST
        - GET
        - PUT
        - PATCH
        - DELETE
      allowed_headers:
        - Authorization
        - Content-Type
      exposed_headers:
        - Content-Type
      allow_credentials: true
      debug: true

errors:
  fallback:
    - json

  handlers:
    redirect:
      enabled: true
      config:
        to: http://127.0.0.1:4455/login
        when:
          -
            error:
              - unauthorized
              - forbidden
            request:
              header:
                accept:
                  - text/html
    json:
      enabled: true
      config:
        verbose: true

access_rules:
  matching_strategy: glob
  repositories:
    - file:///etc/config/oathkeeper/access-rules.yml

authenticators:
  anonymous:
    enabled: true
    config:
      subject: guest

  cookie_session:
    enabled: true
    config:
      check_session_url: http://kratos:4433/sessions/whoami
      preserve_path: true
      extra_from: "@this"
      subject_from: "identity.id"
      only:
        - ory_kratos_session

  noop:
    enabled: true

authorizers:
  allow:
    enabled: true

mutators:
  noop:
    enabled: true Ory Oathkeeper now looks up a valid session in the request cookies and proxies only authenticated requests. It redirects to login UI if there's no cookie available. ory_kratos_session Adding Kong Now all that is needed is to configure Kong: services:
  kong-migrations:
    image: "kong:latest"
    command: kong migrations bootstrap
    depends_on:
      - db
    environment:
      <<: *kong-env
    networks:
      - intranet
    restart: on-failure

  kong:
    platform: linux/arm64
    image: "kong:latest"
    environment:
      <<: *kong-env
      KONG_ADMIN_ACCESS_LOG: /dev/stdout
      KONG_ADMIN_ERROR_LOG: /dev/stderr
      KONG_PROXY_LISTEN: "${KONG_PROXY_LISTEN:-0.0.0.0:8000}"
      KONG_ADMIN_LISTEN: "${KONG_ADMIN_LISTEN:-0.0.0.0:8001}"
      KONG_PROXY_ACCESS_LOG: /dev/stdout
      KONG_PROXY_ERROR_LOG: /dev/stderr
      KONG_PREFIX: ${KONG_PREFIX:-/var/run/kong}
      KONG_DECLARATIVE_CONFIG: "/opt/kong/kong.yaml"
    networks:
      - intranet
    ports:
      # The following two environment variables default to an insecure value (0.0.0.0)
      # according to the CIS Security test.
      - "${KONG_INBOUND_PROXY_LISTEN:-0.0.0.0}:8000:8000/tcp"
      - "${KONG_INBOUND_SSL_PROXY_LISTEN:-0.0.0.0}:8443:8443/tcp"
      - "127.0.0.1:8001:8001/tcp"
      - "127.0.0.1:8444:8444/tcp"
    healthcheck:
      test: ["CMD", "kong", "health"]
      interval: 10s
      timeout: 10s
      retries: 10
    restart: on-failure:5
    read_only: true
    volumes:
      - kong_prefix_vol:${KONG_PREFIX:-/var/run/kong}
      - kong_tmp_vol:/tmp
      - ./config:/opt/kong
    security_opt:
      - no-new-privileges

  db:
    image: postgres:9.6
    environment:
      POSTGRES_DB: kong
      POSTGRES_USER: kong
      POSTGRES_PASSWORD: kong
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "kong"]
      interval: 30s
      timeout: 30s
      retries: 3
    restart: on-failure
    networks:
      - intranet

  hello: The docker-compose creates three containers db container with PostgreSQL database to store the configuration of services/routes for our API gateway. kong-migrate to run migrations against the database. kong container that exposes port for proxying traffic and port with admin API. 8000 8001 As the last step, we need to create a service for Kong and configure routes. #!/bin/bash

# Creates an secure-api service
# and proxies network traffic to oathkeeper
curl -i -X POST \
  --url http://localhost:8001/services/ \
  --data 'name=secure-api' \
  --data 'url=http://oathkeeper:4455'

# Creates routes for secure-api service
curl -i -X POST \
  --url http://localhost:8001/services/secure-api/routes \
  --data 'paths[]=/'\ Testing You can open or in your browser and there are two possible scenarios: http://127.0.0.1:8000/hello http://127.0.0.1:8000/world You receive (or ). {"message": "Hello microservice"} "World microservice" The browser redirects you to . http://127.0.0.1:4455/login Further steps mutator to have the identity accessible as JWT token for your microservices. Configure id_token the password policy to better suit your use case. Configure . Add two-factor authentication Consider using instead of having an additional reverse proxy inside your network. authentication based on subrequest result can be an excellent plugin to use oathkeeper as a decision API for Kong. Kong auth request

Secure Microservices with Kong and Ory

Nowadays the engineering community has many products for authentication in their frameworks. Lots of them have built-in features for authentication and a lot of libraries available for social sign-in. We have the Django framework, Flask, and python-social-auth to build almost everything we need to authenticate users in the pythonic world. In this article, I'll show you an example of how to add everything we need for the user's authentication without writing lots of lines of code. The code used in this blog post is available on . We'll use , , , , , and . GitHub Flask flask cookie-cutter docker docker-compose Postgres Ory Kratos Ory Keto Let's take a look at the login flow of our application using Ory Kratos and Ory Keto. What we will use in our project is a great tool to bootstrap our project structure. It's always a great idea to have ready-to-use linters, Dockerfile, and package management tools out of the box. Flask cookiecutter Postgres as an RDBMS. We will have two Postgres services running in two containers in this example. I think that it's a great idea to keep it simple without using custom scripts to have multiple databases available in a single docker-compose service. Ory Kratos with UI to authenticate users. Ory Keto as an access control service. Setting up Ory Kratos Ory Kratos will be responsible for storing identity data such as email/login and password. Using the guide we need to copy the contents of to the root of your project and then add the following content to the docker-compose: quickstart contrib/quickstart/kratos/email-password postgres-kratos:
    image: postgres:9.6
    ports:
      - "5432:5432"
    environment:
      - POSTGRES_USER=kratos
      - POSTGRES_PASSWORD=secret
      - POSTGRES_DB=kratos
    networks:
      - intranet

  kratos-migrate:
    image: oryd/kratos:v0.8.0-alpha.3
    links:
      - postgres-kratos:postgres-kratos
    environment:
      - DSN=postgres://kratos:secret@postgres-kratos:5432/kratos?sslmode=disable&max_conns=20&max_idle_conns=4
    networks:
      - intranet
    volumes:
      - type: bind
        source: ./kratos
        target: /etc/config/kratos
    command: -c /etc/config/kratos/kratos.yml migrate sql -e --yes

  kratos:
    image: oryd/kratos:v0.8.0-alpha.3
    links:
      - postgres-kratos:postgres-kratos
    environment:
      - DSN=postgres://kratos:secret@postgres-kratos:5432/kratos?sslmode=disable&max_conns=20&max_idle_conns=4
    ports:
      - '4433:4433'
      - '4434:4434'
    volumes:
      - type: bind
        source: ./kratos
        target: /etc/config/kratos
    networks:
      - intranet
    command: serve -c /etc/config/kratos/kratos.yml --dev --watch-courier

  kratos-selfservice-ui-node:
    image: oryd/kratos-selfservice-ui-node:v0.8.0-alpha.3
    environment:
      - KRATOS_PUBLIC_URL=http://kratos:4433/
      - KRATOS_BROWSER_URL=http://127.0.0.1:4433/
    networks:
      - intranet
    ports:
      - "4455:3000"
    restart: on-failure


  mailslurper:
    image: oryd/mailslurper:latest-smtps
    ports:
      - '4436:4436'
      - '4437:4437'
    networks:
      - intranet

  postgres-keto: Setting up Ory Keto You can get familiar with the concepts of Ory Keto reading the guide. These articles can give you a brief introduction to it. Since we need to manage access to the home page, we need to create a folder at the root of our project and have a file with the following content: quickstart keto keto/keto.yml version: v0.7.0-alpha.1

log:
  level: debug

namespaces:
  - name: app
    id: 1

serve:
  read:
    host: 0.0.0.0
    port: 4466
  write:
    host: 0.0.0.0
    port: 4467 We need the following containers: postgresd-auth is the database for Ory Keto. keto-migrate that takes care of database migrations. keto-perms is a wrapper to work with permissions using a command-line interface. keto runs the server. version: "3.7"

x-default-volumes: &default_volumes
  volumes:
    - ./:/app
    - node-modules:/app/node_modules
    - ./dev.db:/tmp/dev.db

services:
  oathkeeper:
    image: oryd/oathkeeper:v0.38
    depends_on:
      - kratos
    ports:
      - 8080:4455
      - 4456:4456
    command:
      serve proxy -c "/etc/config/oathkeeper/oathkeeper.yml"
    environment:
      - LOG_LEVEL=debug
    restart: on-failure
    networks:
      - intranet
    volumes:
      - ./oathkeeper:/etc/config/oathkeeper

  flask:
    build:
      context: .
    image: "kratos_app_example-development"
    environment:
      - FLASK_APP=autoapp.py
      - FLASK_ENV=development
    networks:
      - intranet
    restart: on-failure
    volumes:
      - type: bind
        source: ./
        target: /app

  postgres-kratos:
    image: postgres:9.6
    ports:
      - "5432:5432"
    environment:
      - POSTGRES_USER=kratos
      - POSTGRES_PASSWORD=secret
      - POSTGRES_DB=kratos
    networks:
      - intranet

  kratos-migrate:
    image: oryd/kratos:v0.8.0-alpha.3
    links:
      - postgres-kratos:postgres-kratos
    environment:
      - DSN=postgres://kratos:secret@postgres-kratos:5432/kratos?sslmode=disable&max_conns=20&max_idle_conns=4
    networks:
      - intranet
    volumes:
      - type: bind
        source: ./kratos
        target: /etc/config/kratos
    command: -c /etc/config/kratos/kratos.yml migrate sql -e --yes

  kratos:
    image: oryd/kratos:v0.8.0-alpha.3
    links:
      - postgres-kratos:postgres-kratos
    environment:
      - DSN=postgres://kratos:secret@postgres-kratos:5432/kratos?sslmode=disable&max_conns=20&max_idle_conns=4
    ports:
      - '4433:4433'
      - '4434:4434'
    volumes:
      - type: bind
        source: ./kratos
        target: /etc/config/kratos
    networks:
      - intranet
    command: serve -c /etc/config/kratos/kratos.yml --dev --watch-courier

  kratos-selfservice-ui-node:
    image: oryd/kratos-selfservice-ui-node:v0.8.0-alpha.3
    environment:
      - KRATOS_PUBLIC_URL=http://kratos:4433/
      - KRATOS_BROWSER_URL=http://127.0.0.1:4433/
    networks:
      - intranet
    ports:
      - "4455:3000"
    restart: on-failure


  mailslurper:
    image: oryd/mailslurper:latest-smtps
    ports:
      - '4436:4436'
      - '4437:4437'
    networks:
      - intranet

  postgres-keto:
    image: postgres:9.6
    ports:
      - "15432:5432"
    environment:
      - POSTGRES_USER=keto
      - POSTGRES_PASSWORD=secret
      - POSTGRES_DB=keto
    networks:
      - intranet

  keto-migrate:
    image: oryd/keto:v0.7.0-alpha.1
    volumes:
      - type: bind
        source: ./keto
        target: /home/ory
    environment:
      - LOG_LEVEL=debug
      - DSN=postgres://keto:secret@postgres-keto:5432/keto?sslmode=disable&max_conns=20&max_idle_conns=4
    command: ["migrate", "up", "-y"]
    restart: on-failure
    depends_on:
      - postgres-kratos
    networks:
      - intranet

  keto-perms:
    image: oryd/keto:v0.7.0-alpha.1
    volumes:
      - type: bind
        source: ./keto
        target: /home/ory
    environment:
      - KETO_WRITE_REMOTE=keto:4467
      - KETO_READ_REMOTE=keto:4466
      - LOG_LEVEL=debug
      - DSN=postgres://keto:secret@postgres-keto:5432/keto?sslmode=disable&max_conns=20&max_idle_conns=4
    depends_on:
      - postgres-kratos
    networks:
      - intranet

  keto:
    image: oryd/keto:v0.7.0-alpha.1
    volumes:
      - type: bind
        source: ./keto
        target: /home/ory
    ports:
      - '4466:4466'
      - '4467:4467'
    depends_on:
      - keto-migrate
    environment:
      - DSN=postgres://keto:secret@postgres-keto:5432/keto?sslmode=disable&max_conns=20&max_idle_conns=4
    networks:
      - intranet
    command: serve


volumes:
  node-modules:
  kratos-sqlite:

networks:
  intranet: Working with policies Keto has configured namespace to use in Flask application. Following the guide I decided to implement simple permission policy for the demo project: app Check whether a User has Access to Something Use keto-cli managing permissions. Use email for without symbol. subjects @ Pros Easy to use and maintain. Can easily be automated using CI/CD pipelines. Cons Lack of UI can be dealbreaker for non-engineering staff This permission policy can violate , or any other compliances due to personal data usage. GDPR HIPAA Flask part HTTP_STATUS_FORBIDDEN = 403


@blueprint.route("/", methods=["GET", "POST"])
def home():
    """Home page."""

    if 'ory_kratos_session' not in request.cookies:
        return redirect(settings.KRATOS_UI_URL)

    response = requests.get(
        f"{settings.KRATOS_EXTERNAL_API_URL}/sessions/whoami",
        cookies=request.cookies
    )
    active = response.json().get('active')
    if not active:
        abort(HTTP_STATUS_FORBIDDEN)

    email = response.json().get('identity', {}).get('traits', {}).get('email').replace('@', '')

    # Check permissions

    response = requests.get(
        f"{settings.KETO_API_READ_URL}/check",
        params={
            "namespace": "app",
            "object": "homepage",
            "relation": "read",
            "subject_id": email,
        }
    )
    if not response.json().get("allowed"):
        abort(HTTP_STATUS_FORBIDDEN)

    return render_template("public/home.html")

@blueprint.route("/oathkeeper", methods=["GET", "POST"])
def oathkeeper():
    """ An example route to demo oathkeeper integration with Kratos """
    return {"message": "greetings"} Nota bene Consider having and packages that use and . Instead of just calling some magic endpoints, your code will be more readable with SDKs. authorization authentication Kratos SDK Keto SDK Please pay attention to configure and . login session cookies It's better to use instead of having Ory Kratos managed by your team just because Ory manages it, and you don't need to enable observability/logging/metrics for your service. Ory Cloud

How to Secure Your Flask Application with Ory Kratos and Ory Keto

You Probably Don't Need OAuth2/OpenID Connect: Here's Why

Photo by on Martin Sanchez Unsplash This article discusses the log4j incident, why people are worried about the open-source software (OSS) supply chain, and how to work towards fixing it. The Spark: Log4Shell Last week (Dec 9th) a major vulnerability was discovered in an open-source logging project for Java called . log4j The vulnerability called would allow anyone to remotely run arbitrary code if they sent a message in the right format to the server. This is one of the worst attacks your system can be susceptible to and if you are interested in the technical details of the problem, here is an . Log4Shell overview The attack surface of Log4Shell is . Amazon, Apple, Google, and the Apache Server are ; it can almost not get bigger than this. staggering affected We will see the real fallout of in the upcoming weeks and months as right now servers worldwide are being scanned and prodded for this vulnerability. Log4Shell Since there have many attacks , the whole conundrum sparked a debate in the OSS and infosec community: Many believe that the OSS ecosystem is , maintainers need to become more professional and make OSS maintainer . been supply chain recently broken a real job Some argued that in this case the problem was not that maintainers were unpaid, burnt out, and taken advantage of, but more how this particular feature was implemented in log4j (Note: is a and problem for ). Maintainer burnout still real significant security Others insisted that open source is - society and capitalism are the real culprits and everyone involved in OSS they are getting into. not broken knows what Open source as a model of distribution, development, or business is not a model of either a dystopian nightmare or a utopian dream. Every project is different and there are no silver bullet solutions to sustainability. Open Source Maintainer as a Real Job It is a real problem that software engineers maintaining critical software infrastructure used by governments and corporations worth billions are not able to make a living off of it. Maintainers often can only work on OSS in their free time. This is fine for a pet project, but critical infrastructure projects, such as Log4j, should be more resilient. There should be some type of collective fund set up. Enough donations to be able to work on their projects full-time are likely a tiny fraction of all open source maintainers. In a perfect world, everyone who is maintaining such an important piece of code can do it full time and with adequate compensation. But this is not a perfect world. The best we can do is work on securing each link in the chain. Sponsorships and are a good start, but not enough to sustain infrastructure development. For example, the Ory ecosystem (most notably Ory Hydra) - used by billion-dollar companies and securing >30 billion requests per month - has received $22k on Open Collective over the last six years. GitHub sponsorships Open Collective That is not a small amount compared to what most other OSS projects receive. Still, if split between the two original core maintainers( and ) it would amount to about 150$/month over the years, which is an absurd amount for a full-time maintainer that requires a deep level of expertise in security, cryptography and web infrastructure - not counting the additional maintainers that have been added to the project since its inception. @aeneasr @zepatrik Towards Sustainable Open-Source Maintainership Making a living off open source software and being able to work full time on it is a dream for many maintainers. At Ory, we are working hard to make this dream come true. All our open source packages are now led by maintainers paid full time for their work. What About Dependencies? Dependencies play a major role in the saga of the Log4j vulnerability and security complications in general. It is mind-boggling how big ‘dependency trees’ can get, in many cases, people had no idea they were even running Log4j between the thousands of dependencies in their stack. Ory depends on many software packages so it is also in our and our users’ best interest to ensure a secure and hardened OSS supply chain. Conclusion “Open source isn’t broken. It’s working exactly as intended, and it’s by far the most powerful force in the technology world, and it will outlive any of the corporations so many people bend over backward to please today.” (source) Fund Open Source Software . How to pay for free software analyzes the codebase and shows OSS dependencies and where to fund them. Back your stack , the same principle as above on GitHub. GitHub Sponsors . How to talk to your company about sponsoring an open source project

What the Log4j Incident Means for Open Source and the Entire Internet 

The Government of Uganda, in collaboration with the Lemon Group (LEMX), has announced a groundbreaking partnership to advance blockchain-powered initiatives aimed at fostering economic growth, increasing transparency, and empowering communities through innovative technology solutions. This partnership solidifies Uganda’s position as a forward-thinking leader in blockchain innovation within Africa and globally. In an official statement, Hon. Oryem Henry Okello, Minister of State for Foreign Affairs/International Relations, emphasized the government’s unwavering commitment to supporting the Lemon Group’s (LEMX) transformative tokenization initiatives. These efforts are expected to drive significant investment opportunities, improve public services, and provide a robust framework for economic modernization. The initial phase of this collaboration will focus on tokenizing housing projects to address Uganda’s housing challenges, ensuring quality and affordability for citizens. With over 60,000 army homes slated for tokenization, this first step towards full tokenization of the country is estimated at around 2 billion USD, representing a pivotal step toward democratizing ownership and fostering financial inclusion. By enabling fractional ownership, Ugandans will have unprecedented access to invest in real estate assets, improving their financial independence. Building on this success, the initiative will expand to other sectors, including traditional housing solutions for broader communities and military personnel. The overarching goal is to enhance transparency in asset management and introduce innovative financial models that empower the nation’s citizens. Often referred to as the “Pearl of Africa,” Uganda’s rich resources and strategic position make it a natural hub for blockchain-powered transformation. The potential for tokenization initiatives is vast, and other efforts such as the expansion to tokenizing coffee in the country, are slated to happen in late 2025. By leveraging the Lemon Group’s (LEMX) expertise in blockchain technology, Uganda is poised to attract global investments, enhance service delivery, and strengthen its economic foundation. “I would like to personally acknowledge my long-standing relationship with Dr. Fahed Merehbi, Co-founder of Lemon Group,” stated Minister Okello. “This partnership reflects a shared vision of using innovation to benefit the people of Uganda and promote sustainable progress for our country.” As part of the broader collaboration, Uganda seeks to establish comprehensive blockchain regulations that foster transparency, promote innovation, and position the nation at the forefront of blockchain-driven economic transformation. This partnership aims to showcase Uganda as a regional leader in blockchain-powered asset management, aligning with its vision for a prosperous, digitally advanced future. The Government of Uganda expresses full support for the Lemon Group (LEMX) and its initiatives and remains confident that this partnership will serve the best interests of Ugandans, global investors, and the broader economy. For more information, please contact: Jason Anderson This article is published under HackerNoon’s Business Blogging program. Do your own research before making any financial decisions. The Government of Uganda, in collaboration with the Lemon Group (LEMX), has announced a groundbreaking partnership to advance blockchain-powered initiatives aimed at fostering economic growth, increasing transparency, and empowering communities through innovative technology solutions. This partnership solidifies Uganda’s position as a forward-thinking leader in blockchain innovation within Africa and globally. In an official statement, Hon. Oryem Henry Okello, Minister of State for Foreign Affairs/International Relations, emphasized the government’s unwavering commitment to supporting the Lemon Group’s (LEMX) transformative tokenization initiatives. These efforts are expected to drive significant investment opportunities, improve public services, and provide a robust framework for economic modernization. The initial phase of this collaboration will focus on tokenizing housing projects to address Uganda’s housing challenges, ensuring quality and affordability for citizens. With over 60,000 army homes slated for tokenization, this first step towards full tokenization of the country is estimated at around 2 billion USD, representing a pivotal step toward democratizing ownership and fostering financial inclusion. By enabling fractional ownership, Ugandans will have unprecedented access to invest in real estate assets, improving their financial independence. Building on this success, the initiative will expand to other sectors, including traditional housing solutions for broader communities and military personnel. The overarching goal is to enhance transparency in asset management and introduce innovative financial models that empower the nation’s citizens. Often referred to as the “Pearl of Africa,” Uganda’s rich resources and strategic position make it a natural hub for blockchain-powered transformation. The potential for tokenization initiatives is vast, and other efforts such as the expansion to tokenizing coffee in the country, are slated to happen in late 2025. By leveraging the Lemon Group’s (LEMX) expertise in blockchain technology, Uganda is poised to attract global investments, enhance service delivery, and strengthen its economic foundation. “I would like to personally acknowledge my long-standing relationship with Dr. Fahed Merehbi, Co-founder of Lemon Group,” stated Minister Okello. “This partnership reflects a shared vision of using innovation to benefit the people of Uganda and promote sustainable progress for our country.” As part of the broader collaboration, Uganda seeks to establish comprehensive blockchain regulations that foster transparency, promote innovation, and position the nation at the forefront of blockchain-driven economic transformation. This partnership aims to showcase Uganda as a regional leader in blockchain-powered asset management, aligning with its vision for a prosperous, digitally advanced future. The Government of Uganda expresses full support for the Lemon Group (LEMX) and its initiatives and remains confident that this partnership will serve the best interests of Ugandans, global investors, and the broader economy. For more information, please contact: Jason Anderson This article is published under HackerNoon’s Business Blogging program. Do your own research before making any financial decisions. This article is published under HackerNoon’s Business Blogging program. Do your own research before making any financial decisions. Business Blogging

Lemon Group (LEMX) and Ugandan Government Team Up for Blockchain-Powered Economic Development

লেমন গ্রুপ (LEMX) এবং উগান্ডার সরকার ব্লকচেইন-চালিত অর্থনৈতিক উন্নয়নের জন্য দলবদ্ধ

Ο Όμιλος Lemon (LEMX) και η κυβέρνηση της Ουγκάντα συνεργάζονται για την οικονομική ανάπτυξη που στηρίζεται σε blockchain

Lemon Group (LEMX) y el gobierno de Uganda se unen para impulsar el desarrollo económico impulsado por blockchain

Lemon Group (LEMX) dan Pemerintah Uganda Bekerja Sama untuk Pengembangan Ekonomi Berbasis Blockchain

Lemon Group (LEMX) e il governo ugandese collaborano per lo sviluppo economico basato sulla blockchain

レモングループ（LEMX）とウガンダ政府がブロックチェーンを活用した経済発展のために提携

Lemon Group (LEMX) жана Уганда өкмөтү блокчейн менен иштеген экономикалык өнүгүү үчүн биригишти

„Lemon Group“ (LEMX) ir Ugandos vyriausybė susivienija už blokų grandinės valdomą ekonominę plėtrą

ब्लकचेन-संचालित आर्थिक विकासको लागि लेमन समूह (LEMX) र युगान्डा सरकारको टोली

د لیمون ګروپ (LEMX) او د یوګانډا حکومت ټیم د بلاکچین ځواک لرونکي اقتصادي پراختیا لپاره

Lemon Group (LEMX) na Mfumo wa Uganda va Hlanganile eka Nhluvukiso wa Ikhonomi lowu Fambiwaka hi Blockchain

Lemon Group (LEMX) và Chính phủ Uganda hợp tác phát triển kinh tế dựa trên công nghệ Blockchain

How Conscious Turing Machine Robots Align with Other Theories of Consciousness

Hey friends 👋 Auth0 and its parent company, Okta, are what developers think of when managing and authorization. Both do, , a great job at implementing secure access for our favorite apps! user authentication in general They are also the tools to help us work with the temperamental 0Auth2. 😅 Though this option deserves to be considered, many decent alternatives are on the market. In the open-source world, we are particularly excited about the below 5 alternatives! Let's dive straight into it 👇 Ory Ory is a big name in the industry. It maintains advanced open-source security software solving authentication, authorization, access control, application network security, and delegation. Ory Kratos is an open-source repository that is Auth0-like. It focuses on the identity, user management, and authentication system for the Cloud. The main features you can expect are: Registration, login, and account management flows for passkeys, biometric authentication, social sign-in, SSO, and multi-factor authentication Pre-built login, registration, and account management pages and components OAuth2 and OpenID Connect provider for single sign-on, API access, and machine-to-machine authorization Low-latency permission checks based on Google's Zanzibar model and with built-in support for the Ory Permission Language Hanko Hanko is an elegant project focused on an open-source authentication and user management solution. Their approach focuses on moving the login beyond passwords. Passkeys are the future, and this was well articulated in the blog post , an article written by Google. The Beginning of the End of the Password Since passkeys were announced only very recently, the ecosystem of devices, browsers, and operating systems is getting ready to move beyond passwords. Hanko has been preparing for this shift, and as of present, it provides: Fast integration with Hanko Elements web components (login box and user profile) API-first, small footprint, cloud-native Availability for self-hosting and on Hanko Cloud. The easiest way to get started with hank is with docker-compose: 1️⃣ Clone this repository: git clone https://github.com/teamhanko/hanko.git 2️⃣ In the newly created hanko folder, run: docker compose -f deploy/docker-compose/quickstart.yaml -p "hanko-quickstart" up --build 3️⃣ After the services are running, the login page can be viewed at . To receive emails without your own SMTP server, Hanko added mailslurper which will be available at . localhost:8888 localhost:8080 Cerbos Cerbos is an authorization layer. It enables you to define context-aware access control rules for your application resources in YAML policies, which are managed and deployed via your Git-ops infrastructure. You can set up a self-hosted Cerbos Policy Decision Point. With Cerbos you can: Define authorization logic in a collaborative IDE and testing environment Collaborate with colleagues to author and share policies in private playgrounds Deploy with a fully hosted CI/CD pipeline Build special policy bundles for client-side or in-browser authorization Here is how Cerbos works with your application (a more advanced explanation can also be found ): 👇 here To try out Cerbos, you can get started with their very fun . 😉 Cerbforce tutorial Zitadel Zitadel is an open-source user management tool that is quickly set up like Auth0. Zitadel is built with a complex multi-tenancy architecture in mind, and it provides solutions to handle B2B customers and partners. Zitadel is built with the following structure in mind: API-first approach Multi-tenancy authentication and access management Strong audit trail due to event sourcing as a storage pattern Actions to react to events with custom code Self-service for end-users, business customers, and administrators CockroachDB or a Postgres database as a storage option You should consider Zitadel if you are interested in leveraging the below features: Multi-tenancy with team management Secure Login Self-service OpenID Connect OAuth2.x SAML2 LDAP Passkeys / FIDO2 OTP If the information above makes you think Zitadel is a good fit for you, you can get started by checking out their guide . here SuperTokens SuperTokens is another open-source authentication solution. The main features you can find on the platform are the following: Various login types: Email/password, Passwordless (OTP or Magic link-based), Social / OAuth 2.0 Access control Session management User management Self-hosted/managed cloud Their architecture is unique because your backend API layer would sit in the middle of your front end and SuperTokens'. This enables easy customizations to the auth logic and allows for a secure session solution. To start with SuperTokens, you can use their practical guide to pick the login type you want and get started . here That's it for this one. ☝️ As you have learned in this article, there are many exciting alternatives to Auth0. You should look into each alternative and determine what service best suits your current or future needs. In the meantime, I invite you to consider supporting these projects by starring them. ⭐️ (We are not affiliated with them. We just think that great projects deserve great recognition.) See you next week, Your Hackernoon buddy 💚 Bap Also published . here

Stories, News & Mentions about ORY

Ory’s Stories on HackerNoon

Ory's News & Mentions