本投稿は TECOTEC Advent Calendar 2021 の19日目の記事です。
はじめに
2021年9月に入社した決済認証システム事業部の田中です。
これまでバックエンドの開発・設計などを担当してきて、今はある案件のPMをやっています。
ふとAPIの認可/認証周りについてなんとなくの理解になっているなと思い、アドベンドカレンダーの記事執筆を機に改めて調べてみました。
すごく簡単ではありますが、OAuthとOpenID Connectについて触れていきます。
目次
OAuthとは?
現在の主流のバージョンは OAuth2.0
で認可に特化した仕組みで、IDとパスワードを受け渡すことなくAPIにアクセスできるようにするのが目的です。
それを踏まえて、ポイントをざっくりまとめると以下の通りになります。
- HTTPSでの通信を必須とし、アクセストークンの盗聴を防ぐようにしている
RFC 6749にて4種類の認可フローが定義されている
フロー 説明 Authorization Code Grant 認可コードと交換する形でアクセストークンを受け渡す Implicit Grant アクセストークンを直接受け渡す Resource Owner Password Credentials Grant ユーザーのIDとパスワードの受け渡しが必須 Client Credentials Grant サーバ間でのシナリオで使う認証のためユーザー認証がない アクセストークン
- APIアクセスを認可してもらうために必要なトークン
- 万が一トークンが盗まれた場合の考慮して有効期限は短めに設定する必要がある
- リフレッシュトークン
- 期限切れで使えなくなったアクセストークンを更新するためのトークン
- 有効期限はアクセストークン比較して長めに設定して長期に渡るアクセスを維持する
OpenID Connectとは?
認可に特化した OAuth2.0
を拡張して認証に関する定義されたもので、現在の主流のバージョンは OpenID Connect 1.0
になります。
- IDトークンを利用してユーザーが本人かどうかの証明を行う
- 上記の証明を行うため、アクセスされるAPI側でも確認処理が必要になる
まとめ
システムを開発する上でセキュリティ対策は付き物なので、主流となっている認可・認証の仕組みを理解するのは改めて大切なことだと思います。
今後も安全なシステムを開発できるよう精進します。