はじめに
はじめまして、Sun*でBackendエンジニアをやっている24卒のAsutoです！
今回は認証・認可について、具体的な認証機能（Authorizationヘッダを用いた認証方法）を用いたフロー図などで、初心者にもわかりやすく解説していきます。
補足：認証と認可を行うサーバーは一般的に分けられる（認可サーバー・認証サーバー）ことも多いですが、今回はまとめて認証・認可を行う「サーバー」として定義しています。
目的
- 認証・認可に手こずってる人をクリアにさせたい
- そもそも認証と認可の違いとは？
- どのような流れで認証・認可が行われているのか？
想定読者
- 初学者（認証・認可に初めて触れる人）
- 認証・認可の違いや流れなどが掴めていない人
そもそも認証・認可とは
- 認証とは、利用者本人の確認を行うことです。
- 認可とは、リソースに対するアクセス権利をユーザーに与えるということです。
といってもイメージがつかないと思うので、もう少し違いをわかりやすくするため、ChatGPTに身近なものに例えてもらいました。
このように、
- 認証：利用者本人の確認を行うこと（"あなたは誰？" に答える）
- 認可：リソースに対するアクセス権限を与えること（"あなたは何ができる？" に答える）
であり、認証と認可は同じようで全く別の概念であるということを理解しておくことが重要です。
Authorizationヘッダを用いた認証
Authorizationヘッダを用いた認証には下記の三つがあります。
- ベーシック認証
- ダイジェスト認証
- Bearer認証
今回は、OAuth 2.0でもよく利用されるBearer認証を取り上げます。
Bearer認証とは
Bearer認証とは、OAuth 2.0で広く使用されているHTTP認証スキームです。トークンベースの認証方式で、トークンをHTTPヘッダに含めてリクエストすることでユーザーの認証・認可を行います。
Bearer認証の仕様は、以下のRFCに詳しく定義されています
Bearer tokenとは
Bearer tokenとは、認証や認可のために使用される一種のトークンです。
HTTPのAuthorizationヘッダにスキームとして指定でき、 Authorization: Bearer <token> のようにして指定することができます。
また、フローについては後述しますが、簡単にレスポンスとリクエストをまとめると下記のようになっています。
- クライアントから Authorization:"Bearer token" を含めたリクエストを投げます。
- それを受け取ったサーバーは
- 成功時にはWWW-Authenticate: Bearer realm="XXXX" 形式のヘッダを含めたレスポンスを返します。
- 失敗時にはWWW-Authenticate: Bearer error="XXXX" 形式のヘッダを含めたレスポンスを返します。
Bearer tokenの構成
上記で説明したようにBearer のような形で「Bearer」キーワードとトークンの値がスペースで区切られた形式を取ります。
認証のフロー
フロー図
認可フロー
フロー図
まとめ
今回は認証・認可に関してトークンベースの認証方法を用いて具体的にクライアント、サーバー間での流れなどを主にまとめました。僕自身、最初の頃は認証・認可の違いがそもそもわからずほぼ一緒では？となってしまい色々と苦労をしました。
そこで、今回のポイントとしては
- 認証認可の違いを理解する。
- 認証・認可のフローを理解する。
- どのように認証・認可を行っているのか。
上記のポイントを抑えることで認証・認可に関して理解が進みやすくなると思います！
現在、実際に手を動かしながら認証・認可を学べるようにハンズオンの記事も作成中ですので認証・認可を初めて実装する人や流れを理解したい人などはそちらで実際に手を動かしながら学んでみてください！
参考
PR
Sun*では、一緒に働く仲間を募集しています。
まずはカジュアル面談からでもお気軽にご応募ください！
▼会社情報はこちら
▼募集要項・ご応募はこちら