質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
JWT(JSON Web Token)

JWT(JSON Web Token)とは、JSONをベースとしたアクセストークンの仕様。電子署名付きのURL safeなJSONのことを指します。電子署名が付いているため、改ざんをチェックできる点がメリットです。

HTTP

HTTP(Hypertext Transfer Protocol)とはweb上でHTML等のコンテンツを交換するために使われるアプリケーション層の通信プロトコルです。

HTTPヘッダー

Hypertext Transfer Protocol(HTTP)の中のHTTPヘッダフィールドはHTTPの要求やレスポンスの機能しているパラメーターが含まれます。その要求もしくはレスポンスライン(メッセージの最初の一行)でメッセージヘッダを作ります。

Q&A

解決済

1回答

3202閲覧

マイクロサービスでの認証認可情報の取り回し方法

BECK_

総合スコア94

JWT(JSON Web Token)

JWT(JSON Web Token)とは、JSONをベースとしたアクセストークンの仕様。電子署名付きのURL safeなJSONのことを指します。電子署名が付いているため、改ざんをチェックできる点がメリットです。

HTTP

HTTP(Hypertext Transfer Protocol)とはweb上でHTML等のコンテンツを交換するために使われるアプリケーション層の通信プロトコルです。

HTTPヘッダー

Hypertext Transfer Protocol(HTTP)の中のHTTPヘッダフィールドはHTTPの要求やレスポンスの機能しているパラメーターが含まれます。その要求もしくはレスポンスライン(メッセージの最初の一行)でメッセージヘッダを作ります。

0グッド

0クリップ

投稿2019/08/16 03:36

編集2019/08/16 04:47

現在簡単なwebアプリケーションを作成してマイクロサービスの概念を勉強中です。

理解した事

  • サービス間は疎結合にしてWebAPIで通信する
  • 独立性や可用性の観点からサービス間を跨ぐ情報の共有は行わない(共有DBや共有メモリ等の利用はNG)
  • とは言えシステム全体ではステートフル的に振る舞う必要がある為、認証認可情報を持ち回る必要がある

##出来た事
とりあえず、認証周りを切り出してマイクロサービス化してみました。
ログイン認証はレガシーな独自承認とgoogleのSSO承認まで出来ました。
いずれの認証方式でも汎用的にしたくJWTで管理しようと考えてます。

##疑問

  • 認証までは出来たけど後続処理でid-tokenをどう持ち回る?

今までのモノリシックなシステムではCookieにセッションIDを保存しており、サーバーへのリクエスト時にCookieヘッダフィールドによしなにセットして自動的に送信される為、リクエスト時にはセッションIDを意識しなくてもを処理が継続出来ていました。

** 要は、Cookie使用時の様に透過的にid-tokenの持ち回りを処理したいと考えていますが、
クライアントサイドはどの様に実装するのがベストプラクティスでしょうか? **

下記のいずれかの方法を採用すると、クライアント側ではid-tokenの存在を特に意識(処理)する事なくid-tokenを持ち回れる様な気がするが正しい実装か?

  • Cookieにid-tokenを保存し自動送信させる
  • queryStringにid-tokenをセットする
  • form内にhiddenで隠す

リクエスト時にhederにid-tokenをセットし送信するのが作法の様ですが、formサブミット時に自動的に送信される仕組みはないのか?

Authorization: Bearer {access-token}

参考にしたURL

https://systemdevs.hateblo.jp/entry/2018/05/15/164651

上記サイトからすると、既存のWEBアプリをマイグレーションする際に全POST処理をJavascriptで送信する様に処理を追加するしか方法は無いのでしょうか?

もしそうだとするとクライアント側にフレームワーク的な何かが無いと、クライアント側のコーディングに負債を抱える事になりそうな気がしています。

参考サイトでも参考書籍でもご教授頂ければ幸いです。
宜しくお願い致します。

補足

既存のモノリシックシステムから都度粒度を勘案して順次マイクロサービス化出来ないかな。。と考えております。
サーバーサイドのアーキテクチャも通常のLAMPスタックからスタートしており、フルスタックでの実装がイメージ出来ておりません。
現時点でサーバーサイドでURLを処理し交通整理するフロントエンドの仕組みが必要かどうかも判断出来ておりません。
本件を考慮するにあたり、アーキテクチャ設計も必須になりますでしょうか?

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

mokemokechicken

2019/08/16 04:27

これはWeb Browserから様々なServiceにリクエストを投げる想定でしょうか? それとも 一旦 Browser -> WebServer -> 各種MicroService という想定でしょうか?
BECK_

2019/08/16 04:36

レスありがとう御座います。 様々なServiceとは自前システムの部品という意味では様々なサービスです。 一方外部サービス連携は今の所シングル・サインオンのみを想定しております。 >一旦 Browser -> WebServer -> 各種MicroService という想定でしょうか? ミニマム実装から理解を深めている所で、ブラウザー <---> マイクロサービスとの想定でしたが、 URLルーティングする層(WebServer)が前段で構えるのが一般的でしょか?
mokemokechicken

2019/08/16 04:56

その辺はどうなんでしょうね。 結局ロジックを、Browser側に集中させるか、サーバ側に集中させるか、みたいな話になるような気もします。 システムが分散するのは、疎結合になるメリットもありますが、 結合テストをちゃんとしないと全体の動作がテストされないので、 その辺がコスト的にひどいことにならないように設計する必要はあると思います。 APIリクエストが増えると応答性能も多少落ちますし、 どの程度で分割するのが適切かは、「開発効率、テスト効率、性能、セキュリティ、スケール柔軟性」など色々な観点から慎重に検討すると良いとは思います。
BECK_

2019/08/16 05:17

有難う御座います。 そうですね。。 弊社Javascriptエンジニアが不足気味で、極力サーバー側でロジックを纏めたいと考えております。 スケール柔軟性とトレンド追従観点からのみ学習スタートした段階ですが、つまるところ仰るとおり考慮しないといけない箇所が多くありそうな気がしてきました。 既存アプリケーションを段階的にマイクロサービス化というアプローチが取れればと思っておりますが、現実問題フルスクラッチが良いのでしょかね...
BECK_

2019/08/16 06:04

読み直してて、理解出来た様な気がします。 >Browser -> WebServer -> 各種MicroService WebServerはブラウザーからのリクエストを受け後方のMicroService に対してAPIの発行を行い、結果を集約してViewを生成してブラウザーに返却するイメージですかね。WebServerはMVCのCとVな感じでしょうか。 ゆくゆくUI部分をネイティブアプリ化した際、APIの発行はクライアントに集中しロジックがクライアントに寄るとの理解でよろしかったでしょうか。 当方ハイブリッド対応をイメージしておりますが、トランザクションレベルで考えるとサービスの粒度も結構悩ましく感じておりますw
mokemokechicken

2019/08/16 06:46

表示側が、「Web」「ネイティブアプリ(iOS, Android)」となるなら、 共通のロジックは極力サーバ側に寄せるほうが良いと思います。 そうしないと、「Web」「iOS」「Android」の最低3つで、同じロジックを実装しないといけないことになります。変更の手間も3倍になりますし、一斉に挙動を変えるのも少し大変です。 サーバ側でまとめると都合が悪い部分だけ、個別にそれぞれ呼ぶようにする方がまず自然な構成に思えます。 ※ 当然アプリケーション次第で事情が変わりそうですが、私の経験上はそんなイメージです。
BECK_

2019/08/16 09:07

クローズしてしまって後にアレですが.. >表示側が、「Web」「ネイティブアプリ(iOS, Android)」となるなら、 >共通のロジックは極力サーバ側に寄せるほうが良いと思います。 との事よく理解出来ます。 その際、WebViewでの実装がモアベターとの理解で宜しかったでしょうか? 僕がネイティブアプリの開発スキルが無いので一般論で結構ですが、上述の様なマルチデバイス実装の場合は皆様はどの様に実装されているのでしょうか。
mokemokechicken

2019/08/16 09:35

(理解されているとは思いますが)アプリでWebViewでやるかは要件や予算次第になると思います。 Hybridっぽいものや、完全にNativeのみの場合など色々あると思います。 この辺は(UIの)品質にどの程度こだわるか、というところですね。 私が所属していた会社では、NativeなViewで基本作って、一部だけWebViewというのは割と多い感じでした。この辺は、開発会社の得意不得意でも方針が変わる気がしますね。
BECK_

2019/08/16 15:55

予算は内製なので多少調整は効くと思いますが たしかにUX含め品質に依存しそうですね。 勉強になります。 丁寧に有難う御座いました!
guest

回答1

0

ベストアンサー

全体像が見えないと何が最適なのか、などは判断が難しいと思いますが、
単にTokenの取り回しのはなしだけを考えると以下のように思いました。
※ 全然ベストプラクティスとかは、わかりません...

対 HTML供給 Web Server

  • Cookieには session_id だけ入れて、サーバ側で session_id -> auto_token を持っておく。
  • 理由: シンプルだし安全確実
  • 補足: これが必要になるのは、HTML供給WebServerから 他のAPIサーバにTokenでアクセスすることが必要な場合になるだろう

対 他の API Server

  • HTML供給WebServerからTokenを取得して(JSに埋め込みか、TokenをAPIで取ってくる(ここはcookieで認証)かして)
  • Authorization Headerにtokenを入れて送信するのが良さそう
  • 理由: 意味的に自然?なんですかね。Headerだとサーバ側で検証ロジックがPlugin的に書きやすいですかね。

投稿2019/08/16 04:48

mokemokechicken

総合スコア948

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

BECK_

2019/08/16 05:29

セッションはサービスを跨げない(跨がない)との理解だったのでセッションを利用しない実装を模索しての投稿でしたが、なにかしらサーバー側で状態を保持し共有する仕組みが必要なようですね?
mokemokechicken

2019/08/16 06:53 編集

おっしゃるとおり、セッションはサービスを跨がないイメージです。 この場合、セッションを管理するのはHTMLを(ページを)出力するサーバだけで良いと思います。 例えば、別途「メール/Push通知管理MicroService」みたいなのがあったとして、そういうところとはセッション(IDに関連付けられた情報)を共有しないです。 逆に、HTMLを出力する(いわゆる普通のWeb)サーバは、セッションを持たないとさすがに成り立たないと思います。
BECK_

2019/08/16 07:25

なるほど理解出来ました。 実装もイメージ出来ます。 有難う御座います。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問