0Pricing
Erlang OTP: Distributed & Fault-Tolerant Systems Programming · レッスン

認証と認可

Erlangサービスにアクセスするプロセスとユーザー向けに、堅牢な認証・認可の仕組みを実装します。

「認証と認可」はCoddyKit上の無料Erlang OTP: Distributed & Fault-Tolerant Systems Programmingレッスンです。 これはレッスン2/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。 これはErlang OTP: Distributed & Fault-Tolerant Systems Programming学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Erlang OTP: Distributed & Fault-Tolerant Systems Programmingコースには全4レッスンが含まれています。

このレッスンの一部はまだ翻訳されておらず、英語で表示されています。

AuthN & AuthZ Explained

In distributed systems, knowing who is accessing your services and what they are allowed to do is critical for security. This is where authentication and authorization come in.

  • Authentication (AuthN): Verifies the identity of a user or process. It answers the question, "Who are you?"
  • Authorization (AuthZ): Determines if an authenticated user or process has permission to perform a specific action or access a resource. It answers, "What are you allowed to do?"

They work hand-in-hand to secure your Erlang applications.

Identifying Users

For user authentication, we typically verify credentials like a username and password. In Erlang, you might have a dedicated service (often a GenServer) responsible for managing user accounts and validating login attempts.

This service would receive a login request, check the provided credentials against stored data, and respond with either success or failure. On success, it might issue a session ID or token.

Building an Auth GenServer

Let's create a very basic auth_service using GenServer. For simplicity, it will store a hardcoded user and password. In a real system, you'd integrate with a database and securely hash passwords.

Our auth_service will have a login/2 function that clients can call to authenticate.

Runnable Auth Service

Try running this simple authentication service. You can call auth_service:login("user", "pass") and auth_service:login("wrong", "pass") to see the different responses.

-module(auth_service).
-behaviour(gen_server).

-export([start_link/0, login/2]).
-export([init/1, handle_call/3, handle_cast/2, handle_info/2,
             terminate/2, code_change/3]).

% Client API
start_link() ->
    gen_server:start_link({local, ?MODULE}, ?MODULE, [], []).

login(Username, Password) ->
    gen_server:call(?MODULE, {login, Username, Password}).

% GenServer Callbacks
init([]) ->
    % Store a simple user/pass for demonstration
    Users = #{<<"user">> => <<"pass">>},
    {ok, Users}.

handle_call({login, Username, Password}, _From, State) ->
    case maps:get(Username, State, undefined) of
        Password ->
            {reply, {ok, <<"authenticated">>}, State};
        _ ->
            {reply, {error, <<"invalid_credentials">>}, State}
    end;
handle_call(_Request, _From, State) ->
    {reply, {error, unknown_request}, State}.

handle_cast(_Msg, State) ->
    {noreply, State}.

handle_info(_Info, State) ->
    {noreply, State}.

terminate(_Reason, _State) ->
    ok.

code_change(_OldVsn, State, _Extra) ->
    {ok, State}.

What Can You Do?

Once a user is authenticated, the next step is authorization. This means deciding what actions they are allowed to perform. A common way to manage this is through Role-Based Access Control (RBAC).

  • Roles: Groups of permissions (e.g., admin, editor, viewer).
  • Permissions: Specific actions (e.g., create_post, edit_post, delete_post).

Users are assigned roles, and roles are assigned permissions.

Role-Based Access Control

We can extend our auth_service (or a separate service) to manage roles and permissions. It would need to know:

  • Which roles a user has.
  • Which permissions each role grants.

Then, when a service needs to check if a user can perform an action, it asks the authorization service.

Auth Service with RBAC

Here's an updated auth_service that includes a basic RBAC mechanism. It defines roles and permissions and allows checking if a user has a specific permission.

Try calling auth_service:check_permission("user", "read_data") and auth_service:check_permission("user", "delete_data") after logging in.

-module(auth_service).
-behaviour(gen_server).

-export([start_link/0, login/2, check_permission/2]).
-export([init/1, handle_call/3, handle_cast/2, handle_info/2,
             terminate/2, code_change/3]).

% Client API
start_link() ->
    gen_server:start_link({local, ?MODULE}, ?MODULE, [], []).

login(Username, Password) ->
    gen_server:call(?MODULE, {login, Username, Password}).

check_permission(Username, Permission) ->
    gen_server:call(?MODULE, {check_permission, Username, Permission}).

% GenServer Callbacks
init([]) ->
    Users = #{
        <<"user">> => #{
            password => <<"pass">>,
            roles => [<<"viewer">>, <<"editor">>]
        },
        <<"admin">> => #{
            password => <<"admin_pass">>,
            roles => [<<"admin">>, <<"viewer">>]
        }
    },
    Roles = #{
        <<"viewer">> => [<<"read_data">>],
        <<"editor">> => [<<"read_data">>, <<"write_data">>],
        <<"admin">> => [<<"read_data">>, <<"write_data">>, <<"delete_data">>]
    },
    {ok, #{users => Users, roles => Roles}}.

handle_call({login, Username, Password}, _From, State) ->
    Users = maps:get(users, State),
    case maps:get(Username, Users, undefined) of
        #{password := Password} ->
            {reply, {ok, <<"authenticated">>}, State};
        _ ->
            {reply, {error, <<"invalid_credentials">>}, State}
    end;

handle_call({check_permission, Username, Permission}, _From, State) ->
    Users = maps:get(users, State),
    Roles = maps:get(roles, State),
    case maps:get(Username, Users, undefined) of
        #{roles := UserRoles} ->
            HasPermission = lists:any(
                fun(Role) ->
                    case maps:get(Role, Roles, []) of
                        RolePermissions when is_list(RolePermissions) ->
                            lists:member(Permission, RolePermissions);
                        _ -> false
                    end
                end,
                UserRoles
            ),
            {reply, HasPermission, State};
        _ ->
            {reply, false, State} % User not found or not authenticated
    end;

handle_call(_Request, _From, State) ->
    {reply, {error, unknown_request}, State}.

handle_cast(_Msg, State) ->
    {noreply, State}.

handle_info(_Info, State) ->
    {noreply, State}.

terminate(_Reason, _State) ->
    ok.

code_change(_OldVsn, State, _Extra) ->
    {ok, State}.

Securing Your Services

Once you have an authentication and authorization service, other services in your system can use it. A typical flow looks like this:

  1. Client Authenticates: Calls auth_service:login/2.
  2. Receives Session/Token: If successful, the client gets a session ID or token (e.g., a process ID, or a more complex JWT).
  3. Client Makes Authorized Request: When calling another service (e.g., data_service), the client includes its session/token and the action it wants to perform.
  4. Service Authorizes: The data_service calls auth_service:check_permission/2 using the client's identity and the requested action.
  5. Service Responds: If authorized, the action proceeds; otherwise, an error is returned.

Beyond Basic Auth

While our examples are simple, real-world systems need more:

  • Password Hashing: Never store plaintext passwords. Use strong hashing algorithms like bcrypt or pbkdf2.
  • Session Management: Securely generate, store, and validate session tokens. Ensure they expire and can be revoked.
  • Auditing: Log all authentication attempts and authorization checks for security monitoring and forensics.
  • External Identity Providers: Integrate with OAuth2/OpenID Connect for single sign-on.

Erlang's concurrency makes it great for building robust auth services.

AuthN vs AuthZ Check

Consider a user trying to access a secure document in an Erlang application.

Recap: Securing Services

We've covered the fundamentals of authentication and authorization in Erlang:

  • Authentication (AuthN) verifies identity ("Who are you?").
  • Authorization (AuthZ) determines permissions ("What can you do?").
  • We built a simple auth_service using GenServer for both user login and role-based access control (RBAC).
  • Understanding how to integrate these services is key to building secure and robust distributed Erlang applications.

Next, explore how to protect sensitive data itself within your Erlang applications.

よくある質問

「認証と認可」レッスンは無料ですか？

はい。「認証と認可」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、Erlang OTP: Distributed & Fault-Tolerant Systems Programmingコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Erlang OTP: Distributed & Fault-Tolerant Systems Programmingコースには全4レッスンが含まれています。

「認証と認可」で何を学びますか？

Erlangサービスにアクセスするプロセスとユーザー向けに、堅牢な認証・認可の仕組みを実装します。 ブラウザで直接実行するハンズオンコードでErlang OTP: Distributed & Fault-Tolerant Systems Programmingを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

Erlang OTP: Distributed & Fault-Tolerant Systems Programmingを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのErlang OTP: Distributed & Fault-Tolerant Systems Programmingは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン2/4です。

「認証と認可」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このErlang OTP: Distributed & Fault-Tolerant Systems Programmingレッスンでコードを書いて実行できますか？

はい。すべてのErlang OTP: Distributed & Fault-Tolerant Systems Programmingレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

  1. 安全なノード間通信（TLS）
  2. 認証と認可
  3. 機密データの保護
  4. 分散Cookieとノードアクセスの強化
← Erlang OTP: Distributed & Fault-Tolerant Systems Programmingに戻る