はじめまして、Sun*でBackendエンジニアをやっている24卒のAsutoです！
今回は認証・認可について具体的な認証機能（Authorizationヘッダを用いた認証方法）を用いたフロー図などで流れを説明していきます。

補足：認証と認可を行うサーバーは一般的に分けられる（認可サーバー・認証サーバー）ことも多いですが、今回はまとめて認証・認可を行う「サーバー」として定義しています

といってもイメージがつかないと思うので、もう少し違いをわかりやすくするため、ChatGPTに身近なものに例えてもらいました。

このように、

であり、認証と認可は同じようで全く別の概念であるということを理解しておくことが重要です。

Authorizationヘッダを用いた認証には下記の三つがあります。

今回はBearer認証というものに触れますが、基本認証・認可の流れなどはどの認証でもある程度同じです。

Bearer認証とは、OAuth 2.0でよく使用される HTTP 認証スキームです。
OAuth2.0のドキュメントにBearer認証についての仕組みは下記のリンクに詳しく記載されています。

Bearer tokenとは、認証や認可のために使用される一種のトークンです。
HTTPのAuthorizationヘッダにスキームとして指定でき、 Authorization: Bearer <token> のようにして指定することができます。

また、フローについては後述しますが、簡単にレスポンスとリクエストをまとめると下記のようになっています。

クライアントから Authorization:"Bearer token" を含めたリクエストを投げます。
それを受け取ったサーバーは
- 成功時にはWWW-Authenticate: Bearer realm="XXXX" 形式のヘッダを含めたレスポンスを返します。
- 失敗時にはWWW-Authenticate: Bearer error="XXXX" 形式のヘッダを含めたレスポンスを返します。

上記で説明したようにBearer のような形で「Bearer」キーワードとトークンの値がスペースで区切られた形式を取ります。
また、tokenの形式はtoken68の形式で指定することが[RFC 7235]で定められています。

フロー図

認可フロー

フロー図

今回は認証・認可に関してトークンベースの認証方法を用いて具体的にクライアント、サーバー間での流れなどを主にまとめました。僕自身、最初の頃は認証・認可の違いがそもそもわからずほぼ一緒では？となってしまい色々と苦労をしました。
そこで、今回のポイントとしては

上記のポイントを抑えることで認証・認可に関して理解が進みやすくなると思います！
現在、実際に手を動かしながら認証・認可を学べるようにハンズオンの記事も作成中ですので認証・認可を初めて実装する人や流れを理解したい人などはそちらで実際に手を動かしながら学んでみてください！

Sun*では、一緒に働く仲間を募集しています。
まずはカジュアル面談からでもお気軽にご応募ください！

▼会社情報はこちら

▼募集要項・ご応募はこちら