12
8

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

API Connect におけるJWTの認証

Last updated at Posted at 2018-03-05

JWTによる認証の重要化

近年、Serverless化、MicroService化によってJWTによる認証の重要度が増した事は別記事JWTによる認証の分散化に書きました。
すると、API ConnectでJWTを扱う為にはどうすれば良いかが気になります。

JWTの発行元・発行先でのAPI呼び出し

これは、JWTによる認証の分散化のおさらいですが、
JWTは発行元(いわゆるトークン・エンドポイント)があります。おさらいついでに図も載せておきます。

image.png

項番 内容
JWT発行元に対するログイン
JWT発行元でのログインフォームによる認証
JWTの発行
JWTを利用したAPIの実行
JWTの検証(復号後のハッシュ検証)
検証後のAPI実行

JWTを発行するサービスは、Auth0が有名ですが、続々と登場するに違いありません。各種クラウドもそのようなサービスを持っています。
自分で作成するには、下記のようなライブラリを使ったりして、実装すると良いでしょう。

Python: https://github.com/rohe/pyjwkest
Java: https://bitbucket.org/connect2id/nimbus-jose-jwt/wiki/Home
Go: https://github.com/dgrijalva/jwt-go

	token := jwt.New(jwt.SigningMethodHS256)
	token.Claims["exp"] = time.Now().Add(time.Hour * 72).Unix()
	token.Claims["iss"] = "auth.service"
	token.Claims["iat"] = time.Now().Unix()
	token.Claims["email"] = user.Email
	token.Claims["sub"] = user.Username

API Connectはこの図の中のどの役割が可能なのでしょうか。

JWTの発行

実はAPI Connectは、発行元にも、API使用者にもなります。
発行元になるには、jwt-generate ポリシーを使用します。

JWTを作成するには、鍵(JWK)が必要です。これは、細かい事は省きますが共通鍵暗号にする場合、HS256を使用し、JWT発行元JWT検証側で同じ鍵を使用します。

RS256 等は速度的に遅くなりますが公開鍵と秘密鍵の組(対称鍵)ですので発行元と検証側で別々の鍵を使います。

これは、https://mkjwk.org/ 等のサイトで作成できます。その他、前出のライブラリ等を使用しても良いでしょう。
発行者の情報もこのポリシー内で設定できます。

JWTを利用したAPIの利用

API呼び出し時のチェックは、APIのアセンブリに jwt-varidate ポリシーを配置する事で可能です。

これでJWTがauthorization: Bearerヘッダーにない もの、また JWT自体の署名が正当に評価されないものがはじかれます。

ここで先程も述べたように HS256を使用している場合は、JWTを発行した時と同じ鍵(JWK)を使用して、JWTを検証します。
RS256の場合は公開鍵と秘密鍵が別です。
取得したハッシュと発行元が付けた署名が同じ値であれば、検証完了で、APIを使用しても良い事になります。

検証のみのJWT利用

Auth0やGoogle Identity Platformを使用してJWTの発行元を用意する場合、セキュリティの考慮点から鍵を定期的に変えている場合があります。その場合は、GatewayScriptにて 鍵情報を提供しているエンドポイントから公開鍵 を取得し、その鍵を使用してJWTを検証する必要があります。

IBM Cloud Private

IBMが提供しているサービスに、ローカルにKubernetesやIstio等を全て1セットにして導入できる IBM Cloud Privateというものがあります。ここに Helmの Chart経由で API Connectが導入できるようになるかも知れませんので、そうなると Kubernetes上の Micro Service達をJWT認証するケースも出てきます。
その認証フロントとして API Connectを使用する場合、どのようなネットにするかが肝になると思われます。鍵が流出しない・セキュリティ的に問題ない検証環境でしたら最初の HS256を使用したパターンでも問題ないのかと思います。
別出しの認証局にした場合は先の議論のように認証エンドポイントを叩く必要があります。
いずれにしろ世の中は複雑化する一方ですね。

参考情報

・JWTを使用したポリシーのデモ : https://developer.ibm.com/apiconnect/2016/08/16/securing-apis-using-json-web-tokens-jwt-in-api-connect-video-tutorial/
・MicroServiceとKubernetes・JWT : https://classroom.udacity.com/courses/ud615
・UdacityのKubernetes実験リポジトリ:https://github.com/udacity/ud615/blob/master/app/handlers/login.go
・Google Identity Platformのjwks_uri(鍵提供エンドポイント) : https://developers.google.com/identity/protocols/OpenIDConnect#discovery
・API ConnectとAuth0によるセキュア環境の作成: https://github.com/ozairs/apiconnect/tree/master/jwt
・IBM Cloud Private用Chart一覧:https://github.com/IBM/charts

 

12
8
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
12
8

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?