Outhストーリー

今プロジェクトはOuthを貼る作業をしていますが、いい文章のようです.
また,関連記事ではOuthをさらに否定する.
https://d2.naver.com/helloworld/24942

ユーザー、アプリケーション、およびアプリケーションが使用する「ユーザー」サービス。

何があるの?グーグルとかFacebookとかがあります.
ex)私のアプリケーションで文章を書くとき->Google Kelinderにその内容を記録したり、書いた内容を共有したりする
ただし、この作業を行うには、使用しているサービスのライセンスを取得する必要があります.
最も原始的な方法は?彼らが使用しているサービスの接続情報を利用して、私たちは代わりに要求する方法があります.
しかし、この部分はプレイヤーにとって非常に危険です.
そして、私のサービスのセキュリティ責任は非常に重くなりました.
私たちが提案したソリューションはOuthであり、お互いの不便を解消することを目的としています.
これにより、作成したサービスは、使用しているサービスとインタラクティブになります.

Outhで変更した部分

ID、passwordなどの既存の基本データによるライセンスが必要な場合は、Outhを使用して、発行されたaccessTokenを使用して使用しているサービスを選択的に使用できます.
私のアプリケーションでは、Outhを介してこれらのAccessTokenにアクセスし、必要なサービスを使用します.

用語を整理する

上のように整理すると、単語が長すぎます.ここで説明すると、以下のように簡単になります.
user::ユーザー(ResourceOwner)
mine::作成したサービス(クライアント)
彼ら::ユーザーが登録したサービス+使用したいサービス(リソースサーバ+ライセンスサーバ)
三者の関係に注意しなければならない.

登録

mineがそれらを使用するには、まず事前に承認する必要があります.(register)
一般的には以下の条件が必要です.

Client ID :: Client의 식별자
Client Secet :: Client의 비밀번호(이는 노출되면 안된다.)

Authorized redirect URLs :: 인증이 되었음을 Client에서 받을 수 있게 하는 url

NAVER公式コンテンツを参照すれば、この認証方式が理解できる.
https://developers.naver.com/apps/#/register?api=nvlogin

ここで検証します(ResourceOwnerからResourceServer)

登録が完了すると、クライアントは登録したリダイレクトURLでアプリケーションの認証ステータスを知ることができます.(もちろん、urlに対してどのような処理を行うかはクライアントの役割です.)
では、どの機能を使うかについてお話しします.
ResourceServerが提供する機能には、A、B、C、Dがあると仮定します.
ここでクライアントはA,Cを使いたい.
この場合,この3人の関係をシミュレートする.

この機能(ログインなど)を使用するには、これらの画面をResourceOwnerに表示します.

そして簡単なガイドを展示します.(認証を簡略化するためには、NAVERを使用してログインする必要があります.)

このボタンのurlには、ライセンスを登録したときに記録されたすべての情報が含まれています.

このボタンを押すと、実際のResourceOwnerは、実際のユーザーがResourceServerにログインしているかどうかを確認します.
(Outhのみを使用して認証を行う場合、このプロセス自体がクライアントが使用したい機能です.)

ログインしていない場合は、ResourceServerに次のページが表示されます.

上の画面で正常にログインすると、クライアントidの値がリダイレクトするurlの値と同じかどうかが表示されます.

すべてのクエリーが終了すると、リソース所有者にA、Cの機能を使用するかどうかを尋ねます.(正確には、クライアントがこの機能を使用する確認プロセスです.)

ユーザーがプロセスに同意した場合、ResourceServerはそのユーザーがA、C機能の提供に同意したことを格納します.

これにより、リソース所有者がリソースサーバに同意を要求するプロセスが終了します.

リソースサーバのクライアント承認プロセス

処理が完了すると、authorize codeがクライアント設定のcallback urlの後ろに貼り付けられ、送信されます.

ここでresourceserverの後の値は、「検証番号」として機能します.

resource ownerのブラウザではurlをコールバックしてリダイレクトされ、ターゲットクライアントサーバではユーザーの認証番号が取得されます.

クライアントは、認証番号を使用してリソースサーバに直接要求します.このとき必ず以下のメッセージが送られます.

authorize_code :: resource owner가 승인하여 얻은 인증 번호

client_secret :: 클라이언트의 시크릿 키

リクエストのresource serverは、すべての親値が一致しているかどうかを確認します.
最終段階「AccessToken」.クライアントが受信して保存します.
フェーズが終了すると、認証コードは消えます.

AccessTokenで確認:

유저의 정보

유저가 승인한 기능 (A,C)

Client의 시크릿 키

リソースサーバ上のアプリケーションプログラミングインタフェースの使用方法

現在、A、Cの機能を使用するにはAPIが必要です.
これは、サービスが提供するAPIドキュメントを参照する必要があります.

구글캘린더 정보 가지고 올 때,

유저가 체크한 지도 마킹 정보등을 가지고 올 때 등등

NAVERならOuth 20に基づいて、以下の機能を使用できます.

https://developers.naver.com/docs/login/profile/profile.md
複数の言語のコードの例を示します.

もしAccessTokenが終わったら?どうなるんだろう。

上記の手順を経るたびに、AccessTokenが期限切れになるたびに処理する必要がある場合は、非常に困難なことになります.
歯を抜いたのはrefreshToken.
期限切れのAccessTokenでエラーが発生した場合、Refresh Tokenによってリクエストが発行されると、AccessTokenとRefresh Tokenが選択的に再送信されます.

親イメージは標準化された方法で構築されたAuthメソッドであり、プロセスの理解に多くの参考になります.

の最後の部分

概念に詳しくなくても、いくつかの例を見つけてNAVERログイン、KakaoログインなどOuthを追加するのは難しいことではありません.しかし、これらの内部の流れを理解してこそ、正しく使えるので、個人的に整理しました.

ヒントとして

コンセプト+rfcを使用してGoogle検索を行うと、そのコンテンツの標準的なスキームを表示できます.