目次
1.OAuth2とは
OAuth2.0 は 現在、サードパーティ アプリケーションがユーザー データを取得することを承認するために非常に広く使用されている承認メカニズムです。ユーザーは他のログイン方法を選択して giteeを使用でき 、ここではサードパーティ認証が使用されます。OAuth では、 クライアントとリソース所有者という 2 つの異なる役割を分離するための承認レイヤーが導入されています。 ... リソース所有者が同意するその後、リソース サーバーはクライアントにトークンを発行できます。クライアントはトークンを介してデータを要求します。
次に、OAuth2 での役割
1. リソースオーナー（人）保護されたリソースへのアクセスを許可できるエンティティ。リソースの所有者が個人の場合はエンド ユーザーとも呼ばれます。2. リソースサーバー (APP)保護されたリソースを格納し、アクセス トークンを受け入れて検証し、保護されたリソースへのアクセス要求に応答するサーバー簡単に言えば、それは写真にマークされた場所です
3. お客様（認定ウェブサイト）保護されたリソースにアクセスする前に承認が必要なエンティティ。クライアントという用語は、アプリケーション、サーバー、コンピューターなどを特に指すものではありません。4. 認可サーバー (OAuth2 を参照)リソースオーナーの確認と認可取得に成功したら、クライアントにアクセストークンを発行
三、認証プロセス
説明:
クライアントは使用中のアプレットに相当します
リソース所有者は、私の WeChat アカウントに相当します
認可サーバーはOAuth2相当
Resource Server は WeChat に相当します
ユーザーが WeChat を選択して小さなプログラムにログインすると、小さなプログラムはユーザーの WeChat アカウントにリクエストを送信し、ユーザーが [許可] をクリックすると、小さなプログラムは認証情報を OAuth2 (つまり、認証サーバー) に送信します。 、そして認証サーバーは情報を取得した後、トークントークンをアプレットに送信し、アプレットのログインが許可されます。
4、トークンの特徴
トークン アプローチを使用する利点:(1) トークンは時間に敏感で、一般に短期間で変更できず、パスワードは一般に長期間有効です。(2) トークンは発行者によって取り消され、すぐに有効になり、パスワードは通常、変更なしで長期間有効になります。(3) トークンは権限の範囲を設定でき、ユーザーはそれを変更できませんトークンを使用する場合は、トークンの機密性を確保する必要があり、トークンが有効であることが確認された場合、トークンはシステムに入ることができ、それ以外の検証は行われません。
5 つ、4 つの認証方法
インターネット上にはさまざまなシナリオがあるため、 OAuth2 では 4 つのトークン取得方法が定義されており、自分に合った方法を選択できます。(1) 認可コード ( authorization-code )(2) 非表示 ( 暗黙的 )(3) パスワード ( password ):(4) クライアント資格情報 ( クライアント資格情報 )
認証コード
サードパーティ アプリケーションは、最初に認証コードを要求し、次にそのコードを使用してトークンを取得します。最も一般的な用途で、セキュリティが高く、 Web アプリケーションに適しています。認証コードはフロントエンドを介して渡され、トークンはバックエンドに保存されます。オリジン サーバーとの通信はすべてバックエンドで行われます。フロントエンドとバックエンドをこのように分離することで、トークンの漏洩を防ぐことができます。プロセスは次のとおりです。は上記の
1. リソース サーバーがリンクを提供し、ユーザーがクリックすると、認証サーバーにジャンプし、ユーザー データをリソース サーバーに承認します。リソースサーバーによって提供される接続の例:https://b.com/oauth/authorize? response_type=code& client_id=CLIENT_ID& redirect_uri=CALLBACK_URL& scope=readresponse_type=code 、認証コード方式を使用することを意味しますclient_id=CLIENT_ID 、リクエスタのID IDscope = read redirect_uri=CALLBACK_URL 、認証サーバーがリクエストを受け入れた後のリダイレクト接続、および生成されたコードは、この接続に従ってリソースサーバーに送信できますscope=read 、許可されたスコープは読み取り専用です2. ページがジャンプした後、ユーザーは認証サーバーにログインし、リソース サーバーの認可要求に同意または拒否し、認証サーバーredirect_uri アドレスは、生成された認証コードをリソース サーバーに返します。https://resouce.com/callback_url?code=AUTHORIZATION_CODEcode によって返される認証コード3. クライアントが認証コードを取得したら、認証サーバーにリクエストを送信してトークンを申請します。https://b.com/oauth/token? client_id=CLIENT_ID& client_secret=CLIENT_SECRET& grant_type=authorization_code& code=AUTHORIZATION_CODE& redirect_uri=CALLBACK_URLclient_id リソース サーバーのID IDclient_secret=CLIENT_SECRET セキュリティ パラメータ、バックエンドでのみリクエストを送信できますgrant_type=authorization_code は 、認可方式が認可コードであることを示しますcode=AUTHORIZATION_CODE トークンの取得に使用される認証コードredirect_uri=CALLBACK_URL トークン生成後に発行されたアドレス4. 認証サーバーは認可コードを認証し、認可コードを渡してトークンを発行します。{ "access_token":访问令牌, "token_type":"bearer", "expires_in":过期时间, "refresh_token":"REFRESH_TOKEN", "scope":"read", "uid":用户ID, "info":{...} }
隠し道
非表示方法が適切なシナリオ:Web アプリケーションがバックエンドのない純粋なフロントエンド アプリケーションである場合、この時点でトークンをフロントエンドに保存する必要があり、認証コードを申請する手順を省略します。
1. リソースサーバーが接続を提供し、認証サーバーにジャンプします
https://b.com/oauth/authorize? response_type=token& client_id=CLIENT_ID& redirect_uri=CALLBACK_URL& scope=read2. ユーザーは認証サーバーにログインして承認する必要があります. 承認が成功すると、最初のステップで提供された CALLBACK_URLアドレスに従って、 生成されたトークンが返されます.
この方法の特徴: この方法は安全ではなく、セキュリティが低いシナリオに適しています. トークンの有効期間は一般的に比較的短く設定されており, 通常はセッション中に有効です. ブラウザがトークンを閉じると,有効期限が切れます
パスワード
アプリケーションを非常に信頼し、アプリケーションにユーザー名とパスワードを直接伝え、アプリケーションがユーザー名とパスワードを取得した直後にトークンを申請します1. リソースサーバーはユーザーに認証サーバーのユーザー名とパスワードの提供を要求し、それを取得した後、リソースサーバーは認証サーバーにトークンを申請します。https://oauth.b.com/token? grant_type=password& username=USERNAME& password=PASSWORD& client_id=CLIENT_IDgrant_type=パスワード 認証方式username=USERNAME ユーザー名password= PASSWORDパスワードclient_id=CLIENT_ID クライアント ID2. 認証サーバーが本人確認に合格すると、応答でトークンを直接発行し、リソース サーバーは応答でトークンを取得します。
資格
この方法は、コマンド ラインからトークンを要求する、フロントエンドのないコマンド ライン アプリケーションに適しています。1. リソース サーバーはコマンド ラインを使用して、認証サーバーに要求を送信します。https://oauth.b.com/token? grant_type=client_credentials& client_id=CLIENT_ID& client_secret=CLIENT_SECRETgrant_type=client_credentials 資格証明メソッドclient_id=CLIENT_ID クライアント IDclient_secret=CLIENT_SECRET 認証コードこの方法の本当の利点は、ユーザーではなくサードパーティ アプリケーションが複数のユーザーとトークンを共有できることです。