OAuth

この文章は生活コードOAuthを見て勉強のためにまとめた文章です.

総フロー表

今見てもわかりません.でもこの文章を読んで理解できたのかな??

3つのボディ

Resource Server (github)

クライアント(自分のページ)

リソース所有者(ユーザー)

実際、ResourceServerには次の2つの異なる場所がありますが、上記の3つで説明します.
私たちは何なのかを知るだけでいいです.

Resource Server
データサーバ

Authorization Server
認証処理を専門とするサーバ

クライアントからResourceServerに登録します。

リソースサーバごとに異なります.次の3つの面の代表的な思考でいいです.
クライアント、リソースサーバに、次の3つの重要な情報を提供します.

Client ID

クライアントSecret(漏洩x)

Authorized redirect URIs ex) http://client/callback
ライセンスコードを伝達する場合は、上記のアドレスをお知らせください.

リソース所有者の承認

ResourceOwnerクライアントにアクセスしてResourceServerを購入

ResourceOwnerソーシャルログインを使いたい!

クライアントに次のボタンを作成し、ResourceOwnerをクリックします.

羽毛センター登録ボタンa hrefはどんなurlを使うべきですか

<https://resource.server/>
?client_id=1
&scope=B,C
&redirect_uri=https://client/callback

//예시
<https://github.com/login/oauth/authorize>
?client_id=619d8e37e985e7ab3be6
&scope=user //(각 resource server가 정해놨다.)
&redirect_uri=http://3.37.76.224 || <http://localhost:3000>

ResourceOwnerは上のURIにアクセスします.

ResourceServerは、ResourceOwnerにログインするかどうかを決定します.

ログインX:ログイン画面

ログインO:スキップ.

ログイン成功

ResourceServerは2種類をチェックします.

URIのClientID==お持ちのClientID

URIのredirect uri==上に一致するClientIDのredirect uri

ResourceServerは~~権限が正しいかどうかを尋ねます.

ResourceOwnerはパーミッションを許可します.

ResourceServerは、次の情報をClientIDに格納します.

userId:1 scope:B, C

リソースサーバの承認

上記の手順では、ResourceOwnerが承認されている場合は、すぐにクライアントに権限を付与しません.why? 危険.

ResourceServerは、ResourceOwnerに次の認証コードを提供します.ex) Location : https://client/callback?code=3123123

ここでロcation:何ですか?

応答では、上のURIをHeaderの位置に入れることで、応答するResource Ownerのブラウザが自然に上のURIに移動します.

このうち,フロントエンド開発者はリダイレクトしたURIからライセンスコードを取得し,サーバに送信する責任を負う.

クライアントは、認証コードを取得します.

クライアントは、以下のアドレスでリソースサーバに直接接続されています.

<https://resource.server/token>
?grant_type=authorization_code
&code=3123123
&redirect_uri=https://client/callback
&client_id=1
&client_secret=2

Resourceの下の4つの項目を比較した.

client_id

client_secret

redirect_uri

authorization_code

やっとアクセスTokenが届きました

エクセスト貨幣を発行する

やっとOAuthのアクセストークンを受け取ることができました.

authorization codeを使用して検証するため、削除します.

ResourceServerは、認証コードではなく

アクセスTokenをパブリッシュおよび格納します.

Access Tokenクライアントに送信されます.転送されたクライアントはAccess Tokenを保存します.

Access Tokenを使用したリソースサーバAPIの使用

各ResourceServerは、指定されたAPIを使用できます.この場合、独自のAccess Tokenを同時に送信する必要があります.
クライアントがResourceServerにAccess Tokenを渡すには、2つの方法があります.

検索https://...?**access_token="token"**(Googleは可能ですが、他の場所は知りません)

タイトルの承認:Bearer"token"(標準メソッド)
ここでBeareは?
これはOAuthのために提案された認証方法である.(token type)

ヘッダ交換方式は安全だそうです.だから私たちは彼をヘザーに派遣した.

Refresh Token

各Access Tokenには寿命があります.
このとき,保存したRefresh Tokenを用いてAccess Tokenを再取得する.
ResourceServerごとにRefresh Tokenが与えられるのとは異なり、更新するたびに、またはそうではないと言われています.各サイトで確認しておきたいようです!
コアは、Access Tokenの有効期間が終了した後、APIの使用中にエラーが発生した場合に、再度Refresh Tokenを使用してAccess Tokenを取得することである.

総フロー表

もう一度見て、少し理解できます.

ソース

生活コードOAuth