縁側でお茶飲んだりして過ごしたい

日常の記録。ジャンルフリー。

#ochacafe 5(避けては通れない 認証/認可)に行ってきました

OCHaCafeの第5回に行ってきました。

ochacafe.connpass.com

今回は認証と認可に関するお話で、OAuth2.0やOpenIDConnectを例に説明してくれました。
OAuthについては、以前軽く調べたことがありましたが、サイトごとに言ってることが異なり、結局よくわからずじまいでした。

学んだこと

認証と認可の仕組み

仕組みとしては大きく2つ。

  1. SAML2.0
    ActiveDirectory FederationService(AD FS)と連携してSSOの設定をしたりする等、エンタープライズ向け
  2. OpenIDConnect
    他社サービス間で、JSONやRESTベースのメッセージ連携を行う等、コンシューマ向け
    OpenIDConnectは、OAuth2.0の拡張
    OAuth2.0自体は、システム間での情報の共有や認可を行う仕様

認証と認可の違いは、下記の通り。

  • 認証
    認証処理をしたときに確定されたユーザ情報を相手に提供すること
  • 認可
    ユーザが、システムに対して自分のリソースにアクセスすることを許可すること

混同しやすいけど、よくよく漢字の意味を考えたらその通りだなって思いました。
OpenIDConnectは、認証+認可に加えて、ユーザ情報をもっているらしい。

OAuthの認証、認可のフロー

例をもとに説明してくれました。
登場人物は4つ。

  1. リソースオーナ -> 自分
  2. クライアント -> 街の写真屋の印刷サービス
  3. リソースサーバ -> 写真共有サイト
  4. 認可サーバ

認可、認証フローはこんな感じらしい。

  1. まず自分が、印刷サービスを通じて、写真共有サイトから写真を見ようとする(「連携する」ボタンとか)。
  2. すると、認可サーバにリダイレクトされ、ログイン画面が出力される。
  3. ログインすると、印刷サービスに権限与えるよっていう画面が出力される。
  4. OKすると、認可コードが払い出され、そのまま印刷サービスにリダイレクトされる。
  5. 印刷サービスは、払い出された認可コードを利用して、認可サーバにアクセストークンのリクエストをする。
  6. 認可サーバは、認可コードが正しければ、アクセストークンを印刷サービスに払い出す。
  7. 印刷サービスは、アクセストークンをヘッダ等に付与して、写真共有サイトのAPIをコールする。
  8. 写真共有サイトは、アクセストークンを検証して、正しければ写真を返す。

アクセストークンの検証方法は2通りあるとのこと。

  1. JWT(JSON Web Token)であれば、写真共有サイト自身で検証可能、なぜならBase64だから。
  2. 認可サーバの検証機能を利用する。認可サーバは検証機能のエンドポイントを作るのが規定らしい。
    調べたら、作ることは規定ではなさそう。聞き間違い?RFC7662 OAuth 2.0 Token Introspection

ただし、上記フローには注意点があり、認可コードが盗まれたら、誰でもアクセストークンを取得できてしまう。
そのため、RFC7636 Proof Key for Code Exchange by OAuth Public Clientsがあるらしい。
このフローは、下記の通り。

  1. クライアントは、code_challengeというチャレンジコードを発行し、code_challenge_methodという暗号化方式とチャレンジコードを認可サーバに送る。
  2. 認可サーバは、チャレンジコードと、暗号化方式を認可コードと紐づけて保存し、認可コードを返却する。
  3. クライアントは、暗号化方式に従ってチャレンジコードからcode verifierという検証用コードを発行する。
  4. クライアントは、認可コードと検証用コードを紐づけて認可サーバに送る。
  5. 認可サーバは、送られてきた検証用コードから暗号化方式に従ってチャレンジコードを作成し、保存していたチャレンジコードと突合する。合致し、かつ認可コードも正しければ、アクセストークンをクライアントに返却する。

ややこしい。。。

以上がOAuthのフローとのこと。
ちなみに、OAuthのフロータイプは全部で6種類あるらしい。多い。。。

  1. 認可コードフロー
  2. インプリシットフロー
  3. リソース・オーナー・クレデンシャルフロー
  4. クライアント・クレデンシャルフロー
  5. アサーションフロー
  6. バイスコードフロー

OpenID Connectのフロー

OpenID Connectは、追加でIDトークンを発行し、IDトークンを使い回すことで、別クライアントとのID連携ができるようになる。フローは、こんな感じになる。

  1. ユーザは、印刷サービスサイト上でログインボタンを押す。
  2. 認可サーバにリダイレクトされ、ログイン画面とともに認可していいかが問われる。
  3. ログインすると、認可コードが発行され、印刷サービスサイトにリダイレクトされる。
  4. 印刷サービスは、認可サーバに認可コードを送り、正しければIDトークンとアクセストークンが作成され、印刷サービスに返却される。
  5. 印刷サービスは、IDトークンから対象ユーザ、宛先、有効期限、署名を検証する。
  6. 印刷サービスは、認可サーバにアクセストークンを付与したユーザ情報取得リクエストを行う。
  7. 認可サーバは、必要に応じて追加のユーザ情報を返却する。
  8. 印刷サービスは、ログイン状態を作成し、ユーザはログイン完了となる。

普段何気なく利用している裏でこんなことが行われていたんですね。

さいごに

今まで何となくでしかわからなかったけれども、今回のOCHaCafeを通じて何となくから大体わかるようになりました。
次回は最終回で、5/10(金) OpenAPIのエコシステムについてです。参加予定です。

ochacafe.connpass.com

技術書典6に行ってきました(一般参加)

本日4/14(日)開催の技術書典6@池袋サンシャインシティに行ってきました。初参加です。

techbookfest.org

今回から下記が導入されたようです。

  • 10時から13時までは入場有料(1000円)
  • QRコード読み取りによる後払い方式(技術書典Android/iOSアプリ)

普段からクレカや電子マネーをメインで利用しており、現金をあまり持っていないので、個人的に後払い方式はすごく嬉しい取り組みでした。
もちろん後払いを導入していないサークルもあるので、現金もいくらか持っていきましたが。
次回は、もっと多くのサークルで後払いを導入してほしいですね。

DLC販売も多かったので、私は13時30分くらいに行きました。
既に会場は混んでおり、入場待機列も外まで延びていました。
ただ、結構進みは早く、20分も経たないくらいで入場できました。

場内は、ブース周辺は混んではいましたが、立ち読みスペースなどの開けた場所があるおかげか、流れに乗ればスイスイ移動できました。
ちなみに一般参加者数は、計9300人くらいっだそうです。赤ちゃんベビーカーに乗せてきてた人もいました。

会場には、所々でのぼりが立っており、初参加でも目当てのところへは迷わずに行けました。
あらかじめチェックしていたサークルは6つほどでした。

サークルチェックリスト
サークルチェックリスト

ただ、見本誌を見せていただいたりすると、買わなくてもいいかなあってなったり、
逆に途中で気になった本を手に取り、そのまま購入したりと、
予定よりたくさん買ってしまいました。

f:id:hirano00o:20190414210043p:plainf:id:hirano00o:20190414205402p:plain
戦利品

後払いで購入したものは、明日以降3日以内にPaypalかStripeで支払うとダウンロードできるようになるそうです。
当日手に入らないのは、もどかしいですが、まあ1日で全てが読めるわけじゃないので、物理本を先に読んで待ちます。
また、BOOTHで委託販売しているサークルもあるので、明日以降確認しようかと思います。

イベント自体もそこまで混んでおらず、買いたいものが全て完売!ってこともなかったです。また、いろんな本に触れることができるので、次回も参加しようかと思っています。
サークル側として参加もしてみたいですね。

OchaCafe#1に参加してきました

Oracle Cloud Hangout Cafe、略してOchaCafeの第1回に参加してきました。
OchaCafe#1 - Kubernetesで作るコンテナベースCI☆CDの夕べ - connpass

今月から始まって、月1ペースで全6回の予定だそうです。

今回のおはなし

テーマは、CICDに対する課題とそれを解決する手法(GitOpS)でした。

GitOpsとは、Gitリポジトリのコードを起点として、オペレーション(アプリやシステムの変更)を行うCDの手法だそうです。
2017年にWeaveworks社によって提唱された手法らしいです。

GitOpsというのが、何を解決してくれるかというと、

  • CIツールがデプロイ先情報を持たなくていい
  • 運用にCIツール固有の操作がなくなる。
  • リポジトリを起点にCIとCDが分離するため、リポジトリが唯一の信頼できる情報源(Single Source of Truth)となり、クラスタの状態が一意に決定される。

らしいです。

あと1つ、CIツールがハックされても勝手にデプロイされない。だそうです。
CIハックされた時点で終わりのような気もしますが。

GitOpsという考え方やメリットは何となくわかりました。
説明の後に、GitOpsのデモもありましたが、WerckerやHelm、Spinnakerなどを利用しており、聞いたことなかったのでさっぱりでした。勉強することいっぱいです。
今の会社にいる限りは、仕事上で使うことはないのでしょうけれども…

おわり

むずかしい、べんきょしよ

次回はMicroservicesの運用・管理だそうです。次も参加します。
OCHaCafe#2 - Microservicesの運用・監視 - connpass