インタビュアー: SSO シングルサインオンと OAuth2.0 の違いを教えてください

您好，我是路人，更多优质文章见个人博客：http://itsoku.com

I. 概要

SSO は Single Sign On の略称で、OAuth は Open Authority の略称で、どちらもアプリケーションにアクセスするためのユーザーパスワードをトークンを使用して置き換えます。プロセス的には非常に似ていますが、概念的には大きく異なります。SSO は誰もがよく知っているはずです。SSO はログイン認証をビジネスシステムから分離し、独立したログインセンターを使用し、ログインセンターにログインした後は、関連するすべてのビジネスシステムがログインせずにリソースにアクセスできるようにします。

OAuth2.0 の原理はあまり馴染みがないかもしれませんが、Web サイトにアクセスしてメッセージを残したいが登録はしたくない場合など、日常生活でよく使用されているのが WeChat 認証です。どちらも業務システムにアカウントとパスワードを持たず、ログインセンターやWeChatサーバーにアカウントとパスワードが保存されている、いわゆるアカウントパスワードの代わりにトークンを利用してアクセスする方法です。アプリケーション。

2. SSO

両者には多くの類似点があるため、以下でそのプロセスを説明しましょう。まず SSO について説明しますが、SSO と OAuth2.0 を比較することで、OAuth2.0 の原理を理解するとよいでしょう。SSO を実装するためのフレームワークは CAS フレームワークなど多数ありますが、以下は CAS フレームワークの公式フローチャートです。特別な注意: SSO はアイデアであり、CAS はこのアイデアを実現するための単なるフレームワークです

上記のプロセスは大まかに次のとおりです。

ユーザーが URL を入力してビジネスシステムにアクセスするProtected Appと、システムはユーザーがログインしていないことを検出し、CAS Server独自のアドレスサービスパラメータを使用してユーザーをシングルサインオンシステムにリダイレクトします。
ユーザーのブラウザはシングルサインオンシステムにリダイレクトされ、システムはユーザーがログインしているかどうかを確認します。これは SSO (ここでは CAS) システムの最初のインターフェイスです。ユーザーがログインしていない場合、インターフェイスはユーザーをログインインターフェースにリダイレクトします。ログインしている場合は、グローバルセッションを設定し、業務システムにリダイレクトします。
ユーザーはパスワードを入力してログインを送信します。このときのログインインターフェースは SSO システムによって提供されることに注意してください。ユーザーのパスワードは SSO システムのみが保存します。
SSO システムはパスワードが正しいかどうかを検証し、正しい場合は SSO システムが発行したチケットを使用して業務システムにリダイレクトします。
ブラウザは業務システムのログインインターフェイスにリダイレクトされます。このログインインターフェイスにはパスワードは必要ありませんが、SSO チケットが含まれています。業務システムは、チケットを使用して SSO システムにユーザー情報の取得を要求します。そしてローカルセッションを設定し、ログインが成功してブラウザに返されたことを示しますsessionId( tomcat で呼び出されますJSESSIONID)。
その後、すべての対話はsessionIdビジネスシステムと対話することによって実行できます。

最も一般的な例は、淘宝網 APP を開くと、ホームページ上に天猫、樹花散、その他のサービスへのリンクがあり、それをクリックすると直接スキップされ、再度ログインできなくなります。

3.OAuth2.0

OAuth2.0 には多くのモードがあります。ここでは OAuth2.0 の認証コードモードについて説明します。OAuth2.0 のプロセスは SSO のプロセスと似ています。OAuth2 には、認可サーバー、リソースサーバー、およびサーバーなどのいくつかの役割があります。使用する場合 SSO を実装する場合、リソースサーバーの役割は必要なく、認可サーバーとクライアントだけで十分です。

認証には認可サーバーを使用するのはもちろん、クライアントは各アプリケーションシステムであり、ログイン成功後にユーザー情報とユーザーの権限を取得するだけで済みます。

ユーザーが Web サイトをクリックして WeChat 認証を使用する場合、Web サイトはビジネスシステムに似ており、WeChat 認証サーバーはシングルサインオンシステムに似ています。
その後、WeChat 認証サーバーは、ログインインターフェイスに似た確認認証ページを返します (もちろん、このページはビジネスシステムではなく WeChat に属します)。
ユーザーはアカウント番号とパスワードを入力するのと同様に承認を確認し、送信後、WeChat は認証してチケットを返し、ビジネスシステムをリダイレクトします。
ビジネスシステムはチケットを使用して WeChat サーバーにアクセスし、WeChat サーバーは公式トークンを返します。ビジネスシステムはそのトークンを使用してユーザー情報を取得できます。

OAuth2.0 の 4 つのモードを簡単に紹介します。

認可コード(認可コード)

認可コード方式とは、サードパーティアプリケーションが最初に認可コードを申請し、次にそのコードを使用してトークンを取得することを意味します。この方法は最も一般的に使用されるプロセスであり、最も高いセキュリティを備えており、バックエンドを備えた Web アプリケーションに適しています。認可コードはフロントエンドを通じて送信され、トークンはバックエンドに保存され、リソースサーバーとの通信はすべてバックエンドで行われます。このようにフロントエンドとバックエンドを分離すると、トークンの漏洩を回避できます。

隠された（暗黙的）

一部の Web アプリケーションは、バックエンドのない純粋なフロントエンドアプリケーションです。現時点では上記の方法は使用できず、トークンをフロントエンドに格納する必要があります。RFC 6749 では 2 番目の方法を指定し、トークンをフロントエンドに直接発行できるようにします。このメソッドには認可コードの中間ステップがないため、(認可コード)「暗黙的」(暗黙的)と呼ばれます。

パスワード（パスワード）

アプリケーションを非常に信頼している場合、RFC 6749 では、ユーザーがアプリケーションにユーザー名とパスワードを直接伝えることもできます。アプリケーションは、「パスワード」と呼ばれるトークンを申請するためにパスワードを使用します。

クライアントの資格情報

最後の方法はクライアント資格情報です。これは、フロントエンドのないコマンドラインアプリケーション、つまりコマンドラインでトークンが要求されるアプリケーションに適しています。

簡単なプロセス

4番目に、いくつかの名詞の違いについて話します。

まず、SSOはアイデアやソリューションであり、抽象的なものであり、私たちがやるべきことはそのアイデアに従って実装することです。

次に、OAuth2は、ユーザーがサードパーティのアプリケーションが別のサーバー上のリソースにアクセスすることを許可するために使用されるプロトコルであり、シングルサインオンには使用されませんが、シングルサインオンを実現するために使用できます。この例で SSO を実装するプロセスでは、保護されるリソースはユーザーの情報 (ユーザーの基本情報とユーザーの権限を含む) であり、ログインしてユーザーにこのリソースへのアクセスを許可する必要があります。OAuth2 サーバーは、トークンの発行とその他の操作。トークンの生成には JWT を使用します。つまり、ユーザーの Access_Token を運ぶために JWT が使用されます。

最後に、Spring Security と Shiro は安全なアクセスとアクセス制御に使用されており、これらはすべて Java で書かれたフレームワークです。

もっと良い記事を

↓↓↓ 点击阅读原文，直达个人博客
你在看吗