DEV Community 👩‍💻👨‍💻

Cover image for OAuth とダンスを: ステップ・バイ・ステップ式 ガイド [翻訳記事]
nabbisen
nabbisen

Posted on • Updated on

OAuth とダンスを: ステップ・バイ・ステップ式 ガイド [翻訳記事]

本記事は、以下の記事の翻訳です:
Dancing with OAuth: a step by step guide by anabella
* 執筆者に許諾を頂いた上で掲載しています。


本記事はもともと freeCodeCamp で公開していたものです

新しいことを学んで実践しようと取り組み始めた時、たいていは決まってすぐに、終わるあての無いダンス・ムーヴを続けてしまっているような気持ちになります。
そこでやけっぱちになって正しいやり方を見つけようと探し回るのですが、現実は厳しく、いま何が起きていて、どうすればその部屋の壁の無い方へ抜け出せるのかを、理解できないのです......。

何かの歯車がうまく噛み合い始めるまでは、ただがむしゃらにやるしか無い状況です。

もしかしたら、私の学習プロセスに原因があるのかもしれません。
あるいはもしかしたら、手引きやチュートリアルが、もっと熟練した人や技術のある人を対象にしているのかもしれません。
しかし私は、対象のテーマについて頭を抱え込んだ挙げ句に、いつでも、キーとなるコンセプトを理解するための、さらにはプロジェクトにそれらをより簡単に適用させるための、易しい手引きがあっても良いのでは、と感じるのです。

そのようなわけで、このたび、願うばかりなのを止めて、自分でやってみるように決心した次第です。
取り扱うのは、私が学んだものの中で、最新のものです。

それは何かと言うと OAuth 2.0 です。

OAuth とは?

基本的なことから始めましょう:
OAuth とは オープンな認可(Open Authorization) のことです。
あるアプリケーションもしくは Web サイトに対して、他の Web サイトが提供するユーザーのプライベートなデータにアクセスすることを、認可するプロセスのことを言います。

ここで言う他の Web サイトとは、たいていの場合、信頼されたアイデンティティ情報のプロバイダ(提供者)として機能します。
リクエストを送信して来たアプリに対して、あなたに関するいくつかの基本的な情報を提供するのです。
それによって、アプリがプロファイル情報を作成できるようになります。
このようにして、あなたは退屈な申込書を埋める必要も、さらなる新しいパスワードを捻出する必要も、無くなるのです 📋

あなたは既にこの仕組みを、少なく見積もってもかなりの回数、使用しています。
実際のところ「Facebook / Google / Github / ... でログインする」をクリックした回数だけ、使用したことになるのです。
その際、次のステップで、同意画面が表示されたことでしょう。
そこでは、あなたの(例えばですが) Facebook のプロファイルの内、どの情報について、 that-hot-new-app.com が読み取る(さらに場合によっては書き込む)ことを許可するか、ということが表示されていましたね。
認可されると、 that-hot-new-app.com は、Facebook の提供するアイデンティティ情報を信頼して、受信したデータをもとに、あなたのプロファイルを自分のデータベースに作成できるようになります。

that-hot-new-app.com と Facebook のやり取りは、多くの場合、ここで終了します。
あなたが Facebook でプロファイル画像を変更しても、インターネット上のすべてのプロファイル画像が変わらないのは、このためです。
アプリが Facebook にふたたび問合せを行って更新後のデータを要求することをしない、というだけのことです。

マリンバのリズムとともに音楽が始まり......

この種の仕組みを構築する目的は、他にもあります。
その内の一つは、より将来性のあるものです:
アイデンティティ情報のプロバイダを、サービス・プロバイダとして利用するのです。
(現在、取組みがなされているテーマです。)
もし実現できれば、定期的にこの仕組みを使いながら、あなたのアプリのユーザーに対して、拡張機能を提供することができるようになります。

良い例があります。
Relive というサービスです。
スポーツのトラッキングアプリ複数に接続することで、あなたが走ったり乗り物に乗ったりしたことに対する、アースビューの動画を生成します。
Relive は、アクティヴィティを終了するタイミングで、動画を生成しますかと問合せて来ます。
Yes を選ぶと、処理を開始して、ソーシャルメディアで自慢できるようになった時に......つまりシェアできるようになった時に 🏅 それを教えてくれます。

ここに述べた二つの利用法には、実際のところ、技術的な差異はありません。
そのため、ソーシャルメディアや Google / Gmail のアカウントを用いてどこへログインしたのかについては、意識しておくべきである、と言えます。

おっかないことのように聞こえたかもしれませんね。
しかし本当のところは怖がるものでは全くありません。
ただ次のことだけを頭に留めておいてください。
あなたは that-hot-new-app.com に対して、あなたに関する何かの情報へのアクセスを認可しているのですが、その詳細については同意画面に表示されます。
将来的に再利用される場合にも、それが基本となります。
承認した権限を意識しておき、信頼が置けないと感じた時にはいつでもそれらを無効化できるようにしておきましょう。

例えば、Google のアカウントを使って that-hot-new-app.com にアクセスしていたとしましょう。
今後は許可させたく無いとなった場合は、ただ Google のアカウント設定 に行き、対象からのアクセスを無効化すれば良いのです。

すべての主要なアイデンティティ情報のプロバイダが、このような操作を行う方法を提供しています。

舞台に立つ前に身だしなみを整えましょう

あなたが that-hot-new-app.com に入場する前に、さらには「お気に入りのアイデンティティ情報のプロバイダでログインする」をクリックする前に、誰かが――おそらくは開発者が――プロバイダのサイト上に機能を実装している必要があります。

こちらに that-hot-new-app.com を登録します。
こうすることで、その後のステップにおいて、プロバイダは誰がプライベートなデータを要求しているのかを把握します。

こちらのステップで、開発者は、アプリケーションに関する情報を設定するはずです。
アプリもしくは Web サイトの名前や――さらに重要なものである――リダイレクト URI のような情報です。
プロバイダ(Google や Facebook などです)は、この情報を使って、リクエストして来たアプリと通信を行い、アプリもしくは Web サイトに対してユーザーが認可した旨を伝えます 💍

あなたが手書きする必要は全くありません。私たちは自分たちがペーパーレスを実現していることに誇りを持っています。

アプリが登録されると、プロバイダは that-hot-new-app.com に対して clientIdclientSecret を送信します。
これらは相互間の通信において使用されます。
登録されたアプリにまつわるユーザ名とパスワードのようなものとして機能します。

アプリケーションの保存後すぐに clientID と clientSecret が送信されます。

非常に重要なことがあります。
アプリケーションの情報(リダイレクト URI や clientId、それからとりわけ clientSecret)は、安全な場所に保持して置く必要があります。
もし誰かがそれらへのアクセスを取得して、それらをもとに、あなたの代わりにプライベートなユーザーデータの送信をプロバイダに要求できるようになり、そこから悪意を持った用途にデータが使われることになったとしたら!

そんなことは望みませんよね。

手を相手の腰か肩に回しましょう

開発者は、上述の設定の他にも、どのようなデータがプロバイダから送信されるのかや、それはどのように区分化されているのかについて、理解する必要があります。

この「区分(セグメント)」というのは スコープ として知られています。
アクセス権限を定義するのに使われます。
たいていは、read / write のカテゴリで分けられます。

そこで、例えばですが、 that-hot-new-app.comprofile:readcontacts:read のスコープを要求できるとしましょう。
これは次のことを意味します。
すなわち that-hot-new-app.com は、プロバイダが "profile" ならびに "contacts" にアサインしている情報であれば何であれ、読み取りを行うことができます。かたや変更はできません。
さらに、他の情報にはアクセス自体ができません。例えば、投稿情報や、何にイイねを付けたかという情報です。

さて、今から、事象をシンプルにとらえて行ってみましょう。
準備は良いでしょうか。
that-hot-new-app.com は Web サイトです。
Typeform という、綺麗でスマートなフォームをつくるサービスと統合されています。こちらは私の働く会社でもあります 🤷
あなたはきっと今すぐに最もホットなものの中に飛び込んで、あちこち見て回りたいと思うでしょう。
それでは Web サイトにある「Typeform でログインする」を押して、すぐさま行動に移しましょう。
次に起こるのは何でしょうか?

こちらは手づくりの、オーガニックで、コレステロール・フリーなダイアグラムです。
全体像を表すマップとして使います。
少し複雑に見えるかもしれませんが、心配ご無用です。
この後に各ステップの説明をして行きます。

多彩色のスケッチは私のこころを喜びで包みます

認可: OAuth とダンスを始めるために、最初のステップを踊りましょう

さあ、その手を取って、「Typeform で接続する」を押しましょう。
ほら、 that-hot-new-app.com (THNA と、ここからは記します。ダッシュ区切りの言葉を書くのに疲れてしまいました)が、あなたを Typeform の認可エンドポイント(/oauth/authorize)へ転送します。
その際にこれらのものが提供されます:

  • clientId (THNA のユーザー名であることを頭に留めておいてください)
  • 希望するスコープ(もしくはアクセス権限)
  • リダイレクト URI (再通知)(事前に設定済であるため、Typeform が既に知っている内容ではあります。しかしセキュリティを慎重に担保するという観点から再通知します。)

転送用の URL はこのような姿をしていることでしょう:

https://api.typeform.com/oauth/authorize?client_id=yourClientId&scope=accounts:read+forms:read+results:read
Enter fullscreen mode Exit fullscreen mode

Typeform はこちらの情報を使って、同意画面を生成します。
あなたはそこで、THNA がどの種のものを見たり処理したりできるようになる認可を与えようとしているのかについて、レビューすることができます。

同意画面の生成フロー

同意しようとしている内容を完全に読了してから 「許可する」を幸せな気持ちとともに押せば、Typeform はあなたをリダイレクト URI に転送します。
その際に、一時コードが渡されます。
このような姿をしています:

https://that-hot-new-app.com/auth/redirect?code=xxxXXXxxxXXXxxx
Enter fullscreen mode Exit fullscreen mode

トークン: 次のステップで OAuth とタンゴを(すなわち tangOAuth を)踊りましょう 💃

ここまでの全体としての行ったり来たりを見ると、誰かと一緒にタンゴでくるくる踊っているような気持ちになりませんか?

OAuth とのダンスで次のステップを踊るのは、THNA が先ほどのコードを受け取り、それを OAuth のトークンに変換する時です。

ここまで見て来たように、こちらの舞台では、THAN は要求内容のすべてを表す一時コードを取得しています。
このことは、発信内容を暗号化する方法としてとらえましょう。

「ハイ、私のことを覚えていますか?私は THNA です。こちらのユーザーから、あなたのフォームやテーマを見ることができると聞いています。準備がよろしければ、そのためのトークンを、こちらのリダイレクト URI から送ってください。」

すべてのステップをたどり、且つ、誰のつま先も踏み付け無かったことへのごほうびとして、THNA はまばゆい OAuth のトークンを手にすることでしょう ✨
それを使って、ユーザー(つまりあなたです!)の代わりに、Typeform とやり取りを行い、それが必要とされる場所で認可されたデータを要求することができるようになるのです。

寄り添って(stay)、身体を揺り動かし(sway)ましょう

ここからは、THNA があなたの代わりに Typeform へ送信するすべてのリクエストに対して、アクセストークンとともに認可ヘッダを付与する必要があります。
それをもとにすることで Typeform(もしくは他の何かのプロバイダ)は、次の事柄を識別することができるのです:

  • 誰がデータを要求しているのか(今回の場合、THNA です)
  • 誰に関するデータなのか(あなたですね!)
  • さらには、要求者がそのデータへのアクセスに対して正当な認可を取得しているのは、確かなのか(あなたが同意したものに限ります)

ダンスフロアの準備ができました 👯

さあ、あなたは OAuth とダンスする技術に関して、すべてのステップとスピンを知ったことになります。
ですので、あなたは自分の振り付けをつくり出すことが、すなわちさらなる発展を加えることができるでしょう。
そしてインターネットをさらにすばらしい場所にすることができるでしょう。

*手描きのイラストとともに、敬具


もしあなたが OAuth 2.0 についてより深くより多くのことを実地で体験する方法を求めているのでしたら、私は Net Ninja の PassportJS チュートリアルを強くおすすめします。(NodeJS アプリを題材にして) OAuth 2.0 の構築方法を知る上で必要なすべての基礎が網羅されています。しかも理論と実践のバランスが非常に良いものです。私にとって、ここに記したあらゆる事柄を理解する過程での転換点となる出逢いでした。


お読み頂きどうもありがとうございました。

本記事は、以下の記事の翻訳です:
Dancing with OAuth: a step by step guide by anabella

To Anabella: Thank you so much for your kind permission for me to translate your article.

Top comments (2)

Collapse
 
striderhnd profile image
Erick Gonzales

ありがとございました、この記事は情報量の多いです

Collapse
 
nabbisen profile image
nabbisen

Erick さん、こちらこそどうもありがとうございます☺️
情報量の多さは、原文のすばらしさゆえですね。
イラストまで含めてがんばって翻訳致しました😆

We want your help! Become a Tag Moderator.
Fill out this survey and help us moderate our community by becoming a tag moderator here at DEV.