はじめに

本記事では、Open ID Connectの概要に関して解説を行い、Oktaとの関係性を簡単に紹介します。今後、アプリに対するOpen ID Connectの実装/活用方法に関して深堀した情報を提供していきますのでご期待ください。

(本記事でのOAuthの記載はOAuth 2.0を意味します。)

OAuthとOpen ID Connect

さっそくOpen ID Connectの解説に入りたいところですが、その前にOAuthについて触れます。

Open ID Connectは、OAuthの拡張仕様のため、OAuthについて理解するとOpen ID Connectも理解しやすいです。

OAuthはもともと認可のために制定されたプロトコルであり、Open ID Connectではユーザー認証として活用できるように拡張されました。

認証と認可

まずは、認証と認可について見ていきます。認証と認可の違いは混同されることがありますが、重要な考え方となります。

認証とは本人確認であり、名乗った人物が本人であるかを検証することです。

対して認可はアクセス許可のことであり、システムの所有者が外部のアプリケーションに対してシステムへのアクセスを許可することです。一般にアクセス許可というと、以下のように、ユーザーがシステムへアクセスすることに対して許可をする（以下の図では切符を持っていればアクセスを許可する）図式をイメージされるかと思います。

実際には、この仕組みを実現するには切符を発行する機関と、切符を発行することを許可する人が必要となります。下図の赤字の部分のように、「システムのデータの所有者」を①、「システムへアクセスする人」を②とした場合、①が「切符を発行する人」に対して、『②に切符を発行していいですよ』と伝えます。②は「切符を発行する人」から切符を受け取り、システムへアクセスします。

全体で見ると、①が②に対してシステムへのアクセスを許可していることとなります。この、許可の行為がOAuthでの「認可」となります。

また、システムへは①が所有する情報が格納されているため、「①の情報へのアクセスを②に許可する」ということになります。

IT環境では、①が人間であり、①以外は全てアプリケーションとなります。

具体的な例で考えてみましょう。

Aさんが家に忘れ物をしたため、Bさんに代わりにとって来てもらうとします。Aさんは大家さんに「Bさんに対して私の家の鍵を渡してください」と依頼します。ここが認可（AさんがBさんに対して認可）となります。

大家さんは、そもそもAさんが本人であるかを確認する必要があり、ここで認証も行われるケースが多いです。

Aさんの家がアクセス先のシステムであり、Aさんとしては信頼した人（Bさん）にだけ自分の家にアクセスさせるということになります。

実際のIT環境でのOAuthの使われ方

認証と認可を理解したところで、実際のIT環境でのOAuthの使われ方を見ていきます。

なぜ、OAuthの仕組みが登場したのでしょうか。

例えば、AさんがあるWebサービスへユーザー登録するシーンを想定します。

ここで、Aさんが自分の名前やメールアドレスなどの情報を登録することは手間ですし、複数のWebサービスがある場合にはなおさらです。

もし、AさんがSNSのアカウントを持っている場合には、SNSのサービスのユーザー情報をうまく連携すると便利になります。

そこで、WebサービスからSNSサービスに対してAPIを実行してAさんのユーザー情報を取得するのですが、そのAPIでAさんのSNSのID/PWを使う場合には、AさんのID/PWをWebサービスへ登録する必要があります。このWebサービスからID/PWが漏洩する恐れがありますし、SNS側でPWを変更した際にはWebサービス側に登録しているPWも変更する必要があります。利用するWebサービスの数が増えればこれらのデメリットはさらに高まります。

そこで、ID/PWではなく、一時的に使うことのできるアクセストーンというものを使ってAPIを実行するという仕組みがOAuthの考え方となります。

まさに、前章で紹介した認可の構造となっています。アクセストークンが切符の役割となり、アクセストークンを発行する機関を認可サーバーと呼びます。

アクセストークンの発行の過程を一般化したものがOAuthで、全体のフローは下図となります。

Aさんが認可サーバーに対してアクセス許可の申請を行う際に、認可サーバーはAさんの本人確認を行うことが望ましく、必然的にユーザー認証も実施することとなります。

なお、実際にはユーザー情報を格納するサーバーが認可サーバーの役割を兼任することも多いです。

Open ID Connectへの拡張

前章のように、OAuthではユーザー認証も実施することが多いため、こちらをユーザー認証の仕組みとしても使うことを主な目的として拡張したものが、Open ID Connectとなります。

OAuthとOpen ID Connectの主な違いは以下となります。

Open ID ConnectのフローはOAuthと同じです。

OAuthと同じく、ユーザー情報を格納するサーバーが認可サーバーの役割を兼任することも多く、また、IDトークンに基本的なユーザーの情報が入っているため、IDトークンの情報を利用することで、ユーザー情報取得のAPIを実行する必要がないケースもあります。

Oktaの機能

Open ID Connectではユーザー認証および認可を行う機関が重要であり、ビジネス利用/コンシューマ利用いずれでも活用されています。

Oktaはユーザー情報格納サーバーと認可サーバーの役割を持っており、４つの特長があります。

• OktaがOpen ID Connect用のSDKを提供
• Oktaでのユーザー認証時の柔軟な認証制御
• トークンに含める情報の柔軟なカスタマイズ
• ソーシャルログイン連携

まとめ

認証と認可、OAuthを前提としてOpen ID Connectの仕組みを紹介しました。

Open ID Connectは、ユーザーの認証情報(ID/PWなど)を1か所で管理しながら複数のWebサービスに対してシングルサインオンができ、仕様を標準化することで実装も容易なため、認証・認可の仕組みとして有用であることがご理解いただけたかと思います。

Oktaは柔軟な認証制御の機能をはじめとして、Open ID Connect連携の価値を最大化することが可能です。ぜひご活用ください。