Polski
Zacznij

← Wszystkie szablony · Hasła i logowanie

Wdróż FusionAuth jednym kliknięciem

Zarządzanie tożsamością i dostępem klientów: logowanie, rejestracja, logowanie jednokrotne i MFA dla twoich aplikacji

Alternatywa dla Auth0, Okta i Amazon Cognito, hostowana u siebie.

Czym jest FusionAuth?

FusionAuth to serwer zarządzania tożsamością i dostępem klientów (CIAM): twoje aplikacje webowe, mobilne i API przekazują mu logowanie, rejestrację i zarządzanie użytkownikami. Obsługuje OAuth 2.0, OpenID Connect i SAML 2.0, więc większość frameworków łączy się z nim swoimi standardowymi bibliotekami, a do tego ma własne biblioteki klienckie dla JavaScriptu, Pythona, Javy, Go, PHP, .NET, Ruby i innych języków. Jego hostowane strony logowania logują ludzi hasłem, magic linkiem albo kontem społecznościowym, takim jak Google, Apple czy Facebook, dodają uwierzytelnianie dwuskładnikowe przez aplikację uwierzytelniającą i można je dopasować motywem do wyglądu twojej aplikacji.

FusionAuth tworzy firma FusionAuth, Inc. z Denver, a jego plan Community jest darmowy, bez limitu użytkowników; płatne plany dodają funkcje takie jak kody e-mailem i SMS-em, wykrywanie wyciekłych haseł, własne formularze rejestracji i SCIM. To nie jest open source: uruchamiasz go na licencji FusionAuth. Wszystko jest w jednym interfejsie administracyjnym i REST API: aplikacje, tenanty dla oddzielnych pul użytkowników, role, grupy, webhooki, ustawienia JWT i lambdy, które kształtują tokeny.

Ten szablon uruchamia oficjalny obraz FusionAuth w wersji 1.69.4, z bazą danych Postgres 18, którą Nowy projekt tworzy obok, albo jedną z twoich, którą wybierzesz, i wyszukuje użytkowników w Postgresie, bez Elasticsearcha. FusionAuth najpierw uruchamia się na porcie, do którego nikt nie dociera, i tam powstaje jego administrator z wpisanego adresu e-mail i hasła, więc kreator konfiguracji nigdy nie jest otwarty dla obcych. E-maile FusionAuth wysyła przez Resend, SendGrid albo Amazon SES, zależnie od wyboru w oknie „Nowy projekt”, a dopóki nie ustawisz dostawcy w tenancie, nie wysyła ich wcale.

Hosting FusionAuth na Pethost

  1. Logujesz się do Pethost kluczem dostępu, przez GitHub albo Google. Nie masz jeszcze maszyny? Wybierasz plan, a link czeka, aż będzie gotowa.
  2. Okno „Nowy projekt” otwiera się na aplikacji FusionAuth. Wypełniasz to, o co prosi, i klikasz „Utwórz projekt”: E-mail, Hasło administratora.
  3. E-mail jest opcjonalny: żeby aplikacja FusionAuth go wysyłała, wybierasz w oknie „Nowy projekt” Resend, SendGrid lub Amazon SES i wklejasz to, co daje ci dostawca.
  4. Okno „Nowy projekt” tworzy też nową bazę danych dla aplikacji FusionAuth i podłącza ją przed pierwszym uruchomieniem aplikacji: Postgres (512 MB). Albo wybierasz jedną ze swoich baz Postgres: aplikacja FusionAuth dostaje w niej własnego użytkownika i własną bazę danych, których inne aplikacje tam nie odczytają, a wszystkie aplikacje tej bazy mają wspólny backup i są przywracane razem.
  5. Za minutę czy dwie aplikacja FusionAuth działa pod własnym adresem z HTTPS. Jej sekrety są tworzone losowo, a dane trafiają do nocnego backupu.
  6. To projekt jak każdy inny: ty albo twój agent możecie go zmienić, cofnąć do wcześniejszej wersji albo przywrócić.

Pytania o FusionAuth

Czy FusionAuth jest darmowy?

Plan Community FusionAuth można hostować u siebie za darmo, bez limitu użytkowników i z podstawowymi funkcjami: OAuth 2.0, OpenID Connect i SAML, logowaniem kontami społecznościowymi, MFA przez aplikację uwierzytelniającą, motywami i pełnym API. Płatne plany dodają kody e-mailem i SMS-em, wykrywanie wyciekłych haseł, własne formularze rejestracji, SCIM i wykrywanie zagrożeń. Z FusionAuth można korzystać za darmo, ale nie jest to open source.

FusionAuth czy Auth0: co wybrać?

Oba logują użytkowników przez OAuth 2.0, OpenID Connect i SAML, z logowaniem kontami społecznościowymi i MFA. Auth0 to usługa w chmurze wyceniana według liczby aktywnych użytkowników miesięcznie; plan Community FusionAuth działa tam, gdzie go hostujesz, za darmo dla dowolnej liczby użytkowników, a jego dane zostają w twojej bazie danych.

Jak dodać logowanie do mojej aplikacji przez FusionAuth?

Utwórz aplikację w interfejsie administracyjnym FusionAuth i dodaj adres callback swojej aplikacji jako autoryzowany adres przekierowania. Potem twoja aplikacja wysyła użytkowników na hostowaną stronę logowania FusionAuth przez bibliotekę OpenID Connect, z identyfikatorem klienta (client ID) i sekretem tej aplikacji, i dostaje z powrotem ich tokeny.

Czy FusionAuth obsługuje social login i klucze dostępu?

Tak. Sekcja Identity Providers dodaje do strony logowania Google, Apple, Facebook, Twitter i dowolnego dostawcę OpenID Connect lub SAML 2.0 już w planie Community. Klucze dostępu (WebAuthn) wymagają darmowego planu Licensed Community, zarejestrowanego w portalu konta FusionAuth.

Czy FusionAuth może przenieść użytkowników z Auth0 albo Firebase?

Tak. Jego User Import API przyjmuje istniejące hashe haseł, więc użytkownicy zachowują swoje hasła, a FusionAuth opisuje w dokumentacji migracje z Auth0, Amazon Cognito, Firebase, Keycloaka i innych.

Ile pamięci i miejsca na dysku potrzebuje FusionAuth?

FusionAuth działa na Javie: w spoczynku zajmuje około 600–800 MB pamięci obok bazy Postgres z 512 MB, więcej przy wielu użytkownikach i logowaniach; jego baza danych rośnie powoli, razem z użytkownikami i zapisami ich logowań. Okno „Nowy projekt” daje każdej bazie danych aplikacji tyle pamięci, ile zaleca szablon, chyba że to zmienisz: Postgres (512 MB). Na Pethost wystarczy mu plan Starter, z miejscem na inne aplikacje obok.

FusionAuth: plik Docker Compose

Szablon to ten compose.yaml i zmienne zapisywane do .env projektu przy jego tworzeniu. Pethost uruchamia plik dokładnie tak, jak jest napisany. Maszyna zapisuje tam, jak aplikacja loguje się do swoich baz danych, gdy je podłącza. Okno „Nowy projekt” zapisuje tam wybrane w nim ustawienia e-maila albo zostawia je puste, gdy aplikacja nie wysyła e-maili.

Kontenery: fusionauth (fusionauth/fusionauth-app:1.69.4).

Bazy danych, każda jako osobny projekt: Postgres (512 MB).

services:
  fusionauth:
    image: fusionauth/fusionauth-app:1.69.4
    restart: unless-stopped
    environment:
      # FusionAuth reads DATABASE_URL as a JDBC URL, so it is made here from the part's parts.
      DATABASE_URL: jdbc:postgresql://${DATABASE_HOST:?reload New project to link a Postgres database, or send link_databases with env_prefix DATABASE}:${DATABASE_PORT:?reload New project to link a Postgres database, or send link_databases with env_prefix DATABASE}/${DATABASE_NAME:?reload New project to link a Postgres database, or send link_databases with env_prefix DATABASE}
      DATABASE_USERNAME: ${DATABASE_USER:?reload New project to link a Postgres database, or send link_databases with env_prefix DATABASE}
      DATABASE_PASSWORD: ${DATABASE_PASSWORD:?reload New project to link a Postgres database, or send link_databases with env_prefix DATABASE}
      # Silent mode makes the schema in the linked database, which the app's user owns, and
      # applies a new release's migrations at its start; production mode never shows the
      # migration screen to a visitor.
      FUSIONAUTH_APP_SILENT_MODE: "true"
      FUSIONAUTH_APP_RUNTIME_MODE: production
      # Users are searched in Postgres, with no Elasticsearch or OpenSearch beside it.
      SEARCH_TYPE: database
      FUSIONAUTH_APP_MEMORY: 512M
      # 20 connections at most, FusionAuth's default, within the 47 of the Postgres part.
      DATABASE_MAXIMUM_POOL_SIZE: "20"
      URL: ${URL}
      ADMIN_EMAIL: ${ADMIN_EMAIL}
      ADMIN_PASSWORD: ${ADMIN_PASSWORD}
      SETUP_API_KEY: ${SETUP_API_KEY}
      # The mail provider picked in New project, by STARTTLS on its port; with none, FusionAuth
      # sends no mail until one is set on the tenant.
      SMTP_HOST: ${SMTP_HOST}
      SMTP_PORT: ${SMTP_PORT}
      SMTP_USER: ${SMTP_USER}
      SMTP_PASSWORD: ${SMTP_PASSWORD}
      SMTP_FROM: ${SMTP_FROM}
      SMTP_FROM_NAME: ${SMTP_FROM_NAME}
    # A new FusionAuth shows its setup wizard to whoever opens it first, also in the seconds
    # before Kickstart has run, and counts the setup as done only when Kickstart made the
    # administrator. So FusionAuth runs first on port 9019, which nobody reaches, and only then on
    # port 9011, the page's. On a new database, Kickstart makes the set-up's API key and the
    # administrator, with a stand-in email and password, and gives the default tenant the
    # project's address as its issuer; the API then gives the administrator the email and
    # password of the fields, and the tenant the mail provider, since Kickstart takes a quote or
    # a backslash out of what it is given. The set-up's key is deleted last: while it answers,
    # the set-up is unfinished, and once it is refused and the setup wizard sends a visitor to
    # sign in, FusionAuth is set up.
    command:
      - bash
      - -c
      - |
        set -e
        cd /usr/local/fusionauth
        json() { printf '%s' "$$1" | sed -e 's/\\/\\\\/g' -e 's/"/\\"/g'; }
        # The set-up's API key, and the ids of it and of the administrator, all from SETUP_API_KEY.
        key=$$SETUP_API_KEY
        key_id=$${key:0:8}-$${key:8:4}-$${key:12:4}-$${key:16:4}-$${key:20:12}
        admin_id=$${key:32:8}-$${key:40:4}-$${key:44:4}-$${key:48:4}-$${key:52:12}

        # Kickstart runs only on a FusionAuth with no API key and no user yet.
        cat > /tmp/kickstart.json <<KICKSTART
        {
          "apiKeys": [{"id": "$$key_id", "key": "$$key", "keyManager": true, "description": "The template's set-up"}],
          "requests": [
            {"method": "PATCH", "url": "/api/tenant/#{FUSIONAUTH_TENANT_ID}", "body": {"tenant": {"issuer": "$$URL"}}},
            {
              "method": "POST",
              "url": "/api/user/registration/$$admin_id",
              "body": {
                "user": {"email": "[email protected]", "password": "$$key"},
                "registration": {"applicationId": "#{FUSIONAUTH_APPLICATION_ID}", "roles": ["admin"]}
              }
            }
          ]
        }
        KICKSTART
        FUSIONAUTH_APP_HTTP_PORT=9019 FUSIONAUTH_APP_KICKSTART_FILE=/tmp/kickstart.json fusionauth-app/bin/start.sh &
        first=$$!
        stop_first() {
          kill $$first
          wait $$first 2> /dev/null || true
        }
        api() {
          method=$$1
          path=$$2
          shift 2
          curl -sS -o /tmp/api.json -w '%{http_code}' -X "$$method" -H "Authorization: $$key" \
            -H 'Content-Type: application/json' "$$@" "http://127.0.0.1:9019$$path" 2> /dev/null || true
        }
        refused() {
          echo "FusionAuth refused $$1: $$(cat /tmp/api.json)" >&2
          stop_first
          exit 1
        }

        # Silent mode migrates the database first; a database that does not answer stops the
        # start after 5 minutes, and the next start tries again.
        for wait in $$(seq 300); do
          kill -0 $$first 2> /dev/null || { echo "FusionAuth stopped at its first start." >&2; exit 1; }
          admin=$$(api GET "/api/user/$$admin_id")
          [ "$$admin" = 200 ] && break
          wizard=$$(curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1:9019/admin/setup-wizard || true)
          [ "$$admin" = 401 ] && [ "$$wizard" = 302 ] && break
          sleep 1
        done
        if [ "$$admin" != 200 ] && [ "$$wizard" != 302 ]; then
          echo "FusionAuth did not answer on its first start within 5 minutes." >&2
          stop_first
          exit 1
        fi

        if [ "$$admin" = 200 ]; then
          echo "setting FusionAuth up on a port nobody reaches"
          tenant=$$(grep -o '"tenantId":"[^"]*"' /tmp/api.json | head -n 1 | cut -d '"' -f 4)
          if [ "$${#ADMIN_PASSWORD}" -lt 8 ]; then
            echo "The admin password has fewer than 8 characters, which FusionAuth refuses: give one of 8 or more in ADMIN_PASSWORD of the project's .env, then deploy again." >&2
            stop_first
            exit 1
          fi
          [ "$$(api PATCH "/api/user/$$admin_id" \
            -d "{\"user\": {\"email\": \"$$(json "$$ADMIN_EMAIL")\", \"password\": \"$$(json "$$ADMIN_PASSWORD")\"}}")" = 200 ] \
            || refused "the administrator's email and password"
          if [ -n "$$SMTP_HOST" ]; then
            [ "$$(api PATCH "/api/tenant/$$tenant" -d "{\"tenant\": {\"emailConfiguration\": {\"host\": \"$$(json "$$SMTP_HOST")\",
              \"port\": $$SMTP_PORT, \"security\": \"TLS\", \"username\": \"$$(json "$$SMTP_USER")\", \"password\": \"$$(json "$$SMTP_PASSWORD")\",
              \"defaultFromEmail\": \"$$(json "$$SMTP_FROM")\", \"defaultFromName\": \"$$(json "$$SMTP_FROM_NAME")\"}}}")" = 200 ] \
              || refused "the mail provider"
          fi
          # The set-up's API key can do anything, and nothing needs it any more.
          [ "$$(api DELETE "/api/api-key/$$key_id")" = 200 ] || refused "to delete the set-up's API key"
          echo "FusionAuth is set up, with the administrator $$ADMIN_EMAIL"
        fi
        stop_first
        rm /tmp/kickstart.json

        exec fusionauth-app/bin/start.sh
    healthcheck:
      test: ["CMD", "curl", "-fsS", "-o", "/dev/null", "http://127.0.0.1:9011/api/status"]
      interval: 10s
      timeout: 5s
      retries: 30
      start_period: 300s

Więcej w kategorii Hasła i logowanie