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