【認可】OAuth2.0の簡単な説明

2021年11月28日 03:42

はじめに

@yutakikuchi_です。

ユーザに対して新しいWebやNativeのアプリケーション、WebAPIを提供する際にユーザーが既に使っているGoogleやFacebookなどの外部IDを基にログインしたり、情報へのアクセス権限を管理するということがあるかと思います。悪意のあるアプリなどからのアクセスの攻撃を防ぐなど安全にアクセス権限の管理を行うために利用されるのがOAuthであり、現在はOAuth 2.0が標準となっています。このNoteはOAuthについてのメモを書いておきます。※OAuthの認可の仕組みはムズすぎて、いつも雰囲気で分かったつもりでいます(笑)。

尚、OAuthと同じような仕組みとして、認証も加えたOpenID Connectが存在し、OIDCと略されるようです。

OAuthの前に、認証と認可の違い

外部IDを基にログインしたり、情報へのアクセス権限を管理する

前者のログインを認証(Authentication)と呼びAuthNと略し、後者のアクセス権限を管理することを認可(Authorization) と呼びAuthZと略されます。

実際、Webサービスではログイン認証をすると同時に合わせて権限も付与されるケースが多かったり、Web上のドキュメントでも「認証」とどちらも纏めてしまったり、また開発ソースコードレベルでも区別されずauthやsigninのように同一の表記でされることがあるので混同しがちですが、それらは明確に目的が異なります。

・認証(Authentication) : 「誰」であるかを明確にすること
・認可(Authorization) : 「権限」があるかを明確にすること

アクセス権限があるかどうかの判断を行う認可の代表的な規格としてOAuth2.0というものがあり、それを提供しているのがLogin・ID ProviderであるGoogleやFacebookなどになるということになります。アプリケーションの開発でFirebaseという技術とGoogle OAuth2.0を組み合わせたもので作られる例がありますが、Firebaseはログイン認証機能を提供、Google OAuth2.0はアクセス権限許可をしている認可機能という組み合わせで成り立っているものになります。

OAuth2.0の処理の流れ

OAuth2.0といっても5種類の認可フローが存在して複雑です。下記Qiitaに非常に良く纏まっていますが、その中で代表的な1例だけを図で説明します。OAuth2.0を一言でまとめると、ユーザーがサービスに対してリソースへのアクセス権限を付与するために認可サーバーを経由したToken発行ということになりますが、処理のフローも結構複雑です。

OAuth2.0の図の中に出てくるものは下記となります。
・ユーザー : リソースの保有者、アクセスできる人
・サービスアプリ : 上記ユーザーが使っているWeb・スマホアプリ
・サービスサーバー : サービスアプリのバックエンド、サーバーサイドの仕組み
・認可サーバー : リソースへのアクセス権限を管理しているサーバー
・リソースサーバー : リソースに対してアクセス可能なAPIを提供しているサーバー。具体例はGoogle PhotoやGoogle People APIなど

ユーザーがリソースサーバーに入っているデータに対してサービスからのアクセス許可をするために、ユーザーと認可サーバー間で確認画面上での同意を行った上で認可サーバーがサービスへAccess Tokenを発行。サービスはそのAccess Tokenを持った上でリソースサーバーにリクエストを行い、リソースサーバー内でAccess Tokenの検証がで問題ないことがわかれば、リソース情報のレスポンスを行うという流れになります。

上はあくまでにリソースサーバーへのアクセス権限付与となる「認可」までのフローであり、実際の提供されるアプリのこの後のフローとしてSocial Loginなどの「認証」が入ってくるケースが多いです。

上の図には5つの関係者が記載されていますが、提供事業社単位でまとめると1. ユーザー、2. サービスアプリ・サーバー、3. 認可・リソースサーバー(例Google)のように分かれると思います。ただし、提供されるサービスによってはサービスアプリ・サーバーが別れずに一緒のケースもあると思います。また認可・リソースサーバーについても同様に一緒になるケースもあると思います。

Googleを活用したOAuth2.0だと認可サーバーでユーザーのアクセス権限付与同意とAccess Tokenの発行を行い、そのTokenを基にGoogle People APIなどからユーザーのIDに関する情報を取得するという使い方になると思うので、認可とリソースサーバーは(おそらく)別の環境で成り立っていることになりますね。

まとめ

ユーザーがサービスに対してリソースへのアクセス権限を付与するために認可サーバーを経由したToken発行手段であるOAuth2.0について簡単なメモを書きました。次回以降は「認証」についても触れたいと思います。

この記事が気に入ったらサポートをしてみませんか？