初学者がBearer Tokenを使って認証・認可をざっくり理解してみた！

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

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

### **目的**
- 認証・認可に手こずってる人をクリアにさせたい
	- そもそも認証と認可の違いとは？
	- どのような流れで認証・認可が行われているのか？

### **想定読者**
- 初学者（認証・認可に初めて触れる人）
- 認証・認可の違いや流れなどが掴めていない人

### **そもそも認証・認可とは**
- 認証とは、利用者本人の確認を行うことです。
- 認可とは、リソースに対するアクセス権利をユーザーに与えるということです。

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3736321/c7c275a7-58e1-8452-c81e-9eef0fdc7b6d.png)

このように、
- 認証：利用者本人の確認を行うこと（"あなたは誰？" に答える）
- 認可：リソースに対するアクセス権限を与えること（"あなたは何ができる？" に答える）

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


### **Authorizationヘッダを用いた認証**
Authorizationヘッダを用いた認証には下記の三つがあります。
- ベーシック認証
- ダイジェスト認証
- Bearer認証

今回は、OAuth 2.0でもよく利用される**Bearer認証**を取り上げます。

### **Bearer認証**とは
Bearer認証とは、OAuth 2.0で広く使用されているHTTP認証スキームです。トークンベースの認証方式で、トークンをHTTPヘッダに含めてリクエストすることでユーザーの認証・認可を行います。

Bearer認証の仕様は、以下のRFCに詳しく定義されています

https://datatracker.ietf.org/doc/html/rfc6750

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

また、フローについては後述しますが、簡単にレスポンスとリクエストをまとめると下記のようになっています。
1. クライアントから Authorization:"Bearer token" を含めたリクエストを投げます。
2. それを受け取ったサーバーは
    - 成功時にはWWW-Authenticate: Bearer realm="XXXX" 形式のヘッダを含めたレスポンスを返します。
    - 失敗時にはWWW-Authenticate: Bearer error="XXXX" 形式のヘッダを含めたレスポンスを返します。

https://datatracker.ietf.org/doc/html/rfc6750#section-3

### **Bearer tokenの構成**
上記で説明したようにBearer <token>のような形で「Bearer」キーワードとトークンの値がスペースで区切られた形式を取ります。


https://datatracker.ietf.org/doc/html/rfc7235

### 認証のフロー
**フロー図**
```mermaid
sequenceDiagram

participant　クライアント
participant　サーバー

autonumber
クライアント ->> サーバー: メールアドレスとパスワードを送信する
サーバー ->>　サーバー: ユーザーの存在を検証する
alt 検証してユーザーが存在した場合
    サーバー->>クライアント: tokenを渡す
    クライアント ->> クライアント: tokenを保持する
else 検証しユーザーが存在しなかった場合
    サーバー->>クライアント: エラーを返す
end

```

## 認可フロー
**フロー図**
```mermaid

sequenceDiagram

participant　クライアント
participant　サーバー

autonumber
クライアント ->> サーバー: リクエスト時にtokenを渡す
サーバー ->>　サーバー: tokenの検証をする
alt tokenを検証し、問題なかった場合
    サーバー ->>　サーバー: リソースへのアクセスを行う
    サーバー->>クライアント: リクエストに対してレスポンスを返す
else tokenの検証に失敗した場合
    サーバー->>クライアント: エラーを返す
end

```

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

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


### 参考

https://datatracker.ietf.org/doc/html/rfc6750

https://www.keepersecurity.com/blog/ja/2023/12/26/authentication-vs-authorization-whats-the-difference/#:~:text=%E8%AA%8D%E8%A8%BC%E3%81%A8%E8%AA%8D%E5%8F%AF%E3%81%AE%E4%B8%BB,%E5%B0%8E%E5%85%A5%E3%81%99%E3%82%8B%E5%BF%85%E8%A6%81%E3%81%8C%E3%81%82%E3%82%8A%E3%81%BE%E3%81%99%E3%80%82

https://swagger.io/docs/specification/authentication/bearer-authentication/

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

▼会社情報はこちら

https://sun-asterisk.com/

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

https://sun-asterisk.com/recruitment/