はじめに

こんにちは。TIG-DX の藤井です。

Software Design 2025 年 12 月号 第 1 特集の「今さら聞けない ID 管理 認証基盤を構築する際に知っておくべきこと」に、宮崎さん、市川さん、私の 3 名で寄稿をさせていただきました。

第3章「IDaaS とはどんなサービスか Auth0 から学ぶ機能と選定の勘所」を担当し、Auth0 の機能や活用事例、IDaaS を選定する際の基準等、実際に IDaaS を活用する際に有用な知見を詰め込みました。

本記事にて、簡単に宣伝させていただければと思います。

Software Design とは

技術評論社より月刊で刊行されているOS・Web・プログラミング、技術者のスキルアップのための技術情報雑誌です。当社からも様々な分野についての特集で何度か寄稿をしています。

今回の特集について

そもそも ID 管理とは

世の中には数多くの Web サービスが存在し、その多くがアカウントを作成、ログインすることで利用できるようになっています。企業や学校などに所属している場合も、固有のアカウントが発行され、何らかのサービスを利用することがあると思います。こういったアカウントは、適切にユーザを識別し、ユーザに応じて適切に権限管理するために用いられています。このような仕組みのことを、一般に「ID 管理」と呼び、世にあるサービスの裏側では当たり前のように ID 管理が行われています。

当然のように存在し運用されているのが ID 管理という仕組みです。しかし、その仕組みの裏側は、そう単純ではありません。先述したユーザの識別と適切な権限管理、すなわち認証認可が正常に行えなければ、健全なサービス提供は不可能です。

さらに、ID 管理が行われているサービスを利用する場合、メールアドレスなどのユーザを識別する情報に加え、パスワードをシステムに登録することが多いはずです。これらの情報を紛失・流出させてしまう等があると、信用の失墜・訴訟など、大きな問題に発展してしまうため、適切かつ厳密に管理する必要があります（実際に個人情報が流出してしまったり、悪意ある攻撃者により窃取されてしまった…といった事例は枚挙に暇がありません）。

一方で、ID 管理はサービス提供へ密接に関わる仕組みです。そのため、ユーザにとって煩雑すぎたり、パフォーマンスが不十分だったり、システムの他領域との連携が困難だったりすると、サービスの品質低下にもつながります。

ID 管理を学ぶきっかけとしての本特集

しかしながら、「なんとなくは理解しているが、具体的にどのような仕組みなのか？」「実際構築になるとどうすれば良いのか？」 「フルスクラッチ？ SaaS？ SaaS なら何を使えば良い？」など、より実践的な内容は実は知らない、という方は案外多いかと思います。

ID 管理を伴うサービスを構築・運用している場合であっても、ID 管理に関しては専門家のようなメンバーが存在し、その人依存になってしまっている、というようなこともあるのではないでしょうか。

今回の特集は、まさにそういった方に向けた内容となっています。当然ながら、この特集を一読すれば ID 管理についてすべて理解できる、構築・運用ができるようになる、といったわけではありません。より詳細な技術要素を調べ・学ぶ必要はありますし、継続的に知識をアップデートしていく必要もあります。ただし、その取っ掛かりになる、「詳しい人に聞きたいけど、今更こんなに基本的なことは聞けないなぁ…」といった知識は十二分に得られる内容となっています。

特に、当社が寄稿した第 3 章では、昨今広く利用されている ID 管理のための SaaS、IDaaS である Auth0 について取り上げています。

どういった機能が存在し、どのようなサービスが実現できるのか。少し汎化して、IDaaS を比較する際の観点は何か。といった、IDaaS を活用していくための、実践的な内容を記載しています。ID 管理するにあたって、Auth0 をはじめとする IDaaS を選択肢の1つとして取り入れることができる内容となっているかと思いますので、ぜひご一読いただければと思います。

おわりに

先述の通り、ID 管理は昨今のサービス提供には欠かせないものである一方、意外と詳しい人は少ない、というのが実情だと認識しています。今回の特集を機に、より多くの方が ID 管理の世界に手を伸ばしていただき、より安心・安全・便利なサービスが増えることを願っています。

また、普段から ID 管理には携わっており、Auth0 も活用していますが、今回の寄稿をきっかけに改めて知識を整理・更新できました。雑誌に寄稿するという経験を得られたことも大変ありがたく思っております。このような機会をくださった技術評論社様に、この場を借りてお礼申し上げます。

はじめに

TIG 真野です。

夏といえばコード生成というわけで、HTTP API仕様を定義するOpenAPIの security schemes（認証認可を定義するための箇所）で、Bearer／OAuth2／OpenID Connect (OIDC) 認証を設定すると、各コードジェネレータはどういったコード生成をしてくれるかを調べました。

なお、OpenAPIについてはOpenAPI Specification v3.0.3のコーディング規約を公開しましたの記事も参考ください。

この記事で利用した openapi.yaml や生成したサーバサイドのコードは以下のリポジトリにまとめています。

• https://github.com/ma91n/summer2024

コード生成の対象

• Go言語のみ
• サーバサイドのみ（※クライアントコードは対象外）

比較ツール

Goコードを生成可能な以下のツールを対象にします。今どきはOpen API 3.0.3（3.1.0） を使うと思うので、3系に対応しているツールを選定しています。フューチャー技術ブログではgo-swagger記事がいくつかありますが、go-swaggerは2系にしか対応していないので対象外としています。

1. ogen v1.3.0
2. oapi-codegen v2.2.0 net/http モード、strict-server モード
3. openapi-generator v7.8.0 gorilla/mux ルーターモード

検証の構成やコードについて

構成ですが、クライアントを curl で、JWTトークンをGo製のCLIツールで作成し、OAuth 2.0でいう認可サーバを無くした状態で検証しています（※本来は、公開鍵を /oauth2/jwks や jwks_uri で指定されたURLから取得できるようにすべきですが、ハードコードで省略しています）。

利用するJWTトークンについて

認可サーバやIdPを今回用意しないので、替わりに openssl で秘密鍵・公開鍵を作成します。秘密鍵でJWTを署名し、公開鍵で検証することを想定しているので、非対称鍵系署名アルゴリズムを選定します。

詳しくない領域なので間違っていたらご指摘いただきたいですが、RS256は避けた方が良い というAuthleteさんの話を読み、今回はES512を利用することにします。

# 秘密鍵を生成
openssl ecparam -name secp521r1 -genkey -noout -out ecprivatekey.pem

# 公開鍵を生成
openssl ec -in ecprivatekey.pem -pubout -out ecpubkey.pem

秘密鍵を利用してJWTトークンを生成します。iss、subなど属性は適当にしています。スコープ（scp）は検証に用いたい値です。

package main

import (
	_ "embed"

	"crypto/x509"
	"encoding/pem"
	"fmt"
	"log"

	"github.com/golang-jwt/jwt/v5"
)

//go:embed ecprivatekey.pem
var privateKey []byte

func main() {
	// 参考: https://stackoverflow.com/questions/21322182/how-to-store-ecdsa-private-key-in-go
	block, _ := pem.Decode(privateKey)

	ecPrivateKey, err := x509.ParseECPrivateKey(block.Bytes)
	if err != nil {
		log.Fatal(err)
	}

	s, err := jwt.NewWithClaims(jwt.SigningMethodES512,
		jwt.MapClaims{
			"iss": "my-auth-server",
			"sub": "123",
			"scp": "read:hellos write:hellos",
		}).SignedString(ecPrivateKey)
	if err != nil {
		log.Fatal(err)
	}

	fmt.Println(s)
}

実行するとJWTトークンが標準出力されます。これをAuthorizationヘッダーに利用します。

$ go run .
eyJhbGciOiJFUzUxMiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJteS1hdXRoLXNlcnZlciIsInNjcCI6InJlYWQ6aGVsbG9zIHdyaXRlOmhlbGxvcyIsInN1YiI6IjEyMyJ9.AM5-XwIJM0HBxHeaUt2SXU7fU8UXQhet6DfzP7i0JoTVLwbme36NZ-rG_8URqtUkQ2knvi7D3iydvCGgoDGdHm41Ae3aMDNG-yjwUiH7O9xJVLPly2EkwQC0GdsZU6ax-99t0ePDaeJaNf7k799hgxDQ3op9KCNTr8pDfvR2a6PkLvfQ

openapi.yaml

openapi.yaml の security schemes は次のように記載しています。先述の通り、OAuth 2.0での認可サーバ、OIDCでのIdPは利用しない構成のため、authorizationUrlなどの値はすべてダミー値であり、検証には使われません。

components:
  # ...省略...
  securitySchemes:
    Bearer:
      type: http
      scheme: bearer
      bearerFormat: JWT
      description: 'Bearerトークン認可'
    OAuth2:
      type: oauth2
      flows:
        authorizationCode:
          authorizationUrl: 'https://example.com/oauth2/authorize'
          tokenUrl: 'https://example.com/oauth2/token'
          refreshUrl: 'https://example.com/oauth2/refresh'
          scopes:
            'write:hellos': modify hello in your account
            'read:hellos': read hello in your account
      description: 'OAuth 2.0認可'
    OIDC:
      type: openIdConnect
      openIdConnectUrl: https://example.com/.well-known/openid-configuration
      description: 'OpenID Connect'

各エンドポイントは次のように定義します。認証なし・Bearer認証・OAuth2.0認証・OIDC認証の4パターンです。

paths:
  '/hello':
    get:
      tags:
        - ping
      summary: hello👋
      operationId: hello
      responses:
        '200':
          $ref: '#/components/responses/Hello'
  '/hello-bearer':
    get:
      tags:
        - ping
      summary: hello bearer👋
      operationId: helloBearer
      responses:
        '200':
          $ref: '#/components/responses/Hello'
      security:
        - Bearer: []
  '/hello-oauth2':
    get:
      tags:
        - ping
      summary: hello oauth2👋
      operationId: helloOAuth2
      responses:
        '200':
          $ref: '#/components/responses/Hello'
      security:
        - OAuth2:
            - 'write:hellos'
            - 'read:hellos'
  '/hello-oidc':
    get:
      tags:
        - ping
      summary: hello openid connect👋
      operationId: helloOIDC
      responses:
        '200':
          $ref: '#/components/responses/Hello'
      security:
        - OIDC:
            - 'write:hellos'
            - 'read:hellos'

openapi.yamlの全体は https://github.com/ma91n/summer2024/blob/main/openapi.yaml を参照ください。

検証項目

この openapi.yaml を元にコードを生成し、次の内容がどのように変化するか確認しました。

1. Bearer、OAuth2、OIDC の認証設定によって生成コードがどのように変わるか、変わらないのか
2. 生成された認証設定のコードを各フレームワークでどのように実装するか
3. OAuth2、OIDC でスコープ（write:hellos などの部分）がどう生成コードに影響を与えるか

結果サマリ

【凡例】 ✅️対応あり ✘対応なし

今回の検証における、おすすめ度は記載順で、ogen >= oapi-codegen > openapi-generator といった感覚です。別の角度では全く結果が変わることも想定されますので、あくまで判断材料の一部としての利用、認識いただければです。

1. ogen

セットアップです。

# インストール
go install -v github.com/ogen-go/ogen/cmd/ogen@v1.3.0

# コード生成
ogen --target api --clean openapi.yaml

そのまま実行すると以下のエラーが表示されます。ogen はサーバサイドコード生成だけど OIDC が未対応でした。

$ ogen --target api --clean openapi.yaml
Feature "openIdConnect security" is not implemented yet.

回避としては同一改装に ogen.yaml を用意して次のスキップ設定を追加します（コマンドラインオプションに設定ファイルの指定は不要で、自動で読み込まれるようです）。

generator:
  ignore_not_implemented: ["openIdConnect security"]

ogen.yaml で何が指定できるかはドキュメントに記載が見当たらずでした。ご存知の方はX（旧Twitter）でコメントいただけると幸いです。

さて、ogenですが各エンドポイントの実装詳細は ogensample/hello_handler.go を参照いただきたいですが、感覚で言うと生成コードはシンプルでわかりやすく、ハマるポイントは少ないです。

ただ認可側の実装はドキュメントのMisc > Request lifecycle > security-handlersに記載が少しある程度で少し推測が必要でした。

生成コードを読んでいった方が早いかもしれません。ドキュメントと生成コードを見比べていくと、api/SecurityHandler インターフェースを満たす必要があるとわかります。Bearer認証とOAuth2.0認証ごとに呼ばれる関数が異なる作りのようです。さらに同じ認証方式だけど、あるエンドポイントだけで挙動を変えたい場合は、operationName （openapi.yaml で定義した operationId が入っていました）を用いて拡張可能な作りです。親切！

type SecurityHandler interface { bn
	// Bearerトークン認可. operationNameにはhelloやhelloBearerなどoperationIdの値が入る
	HandleBearer(ctx context.Context, operationName string, t Bearer) (context.Context, error)

	// OAuth 2.0認可.
	HandleOAuth2(ctx context.Context, operationName string, t OAuth2) (context.Context, error)
}

ogenが生成した Bearer や OAuth2 の構造体もシンプル。Tokenはリクエストヘッダの Authorization: Bearer <token> の <token> の値が入っています。OAuth2 側のScopes はopenapi.yaml 側で指定した値が入っています。

type Bearer struct {
	Token string
}

type OAuth2 struct {
	Token  string
	Scopes []string
}

これを満たすように MySecurityHandler を実装します。トークンのチェックはかなり端折った実装になっています。本来は発行者（iss）、アルゴリズム（alg）、用途（aud）、期限（exp）なども確認する必要があるでしょう。

type UserClaim struct {
	jwt.RegisteredClaims
	Scope string `json:"scp"`
}

type MySecurityHandler struct{}

func (o MySecurityHandler) HandleBearer(ctx context.Context, operationName string, t api.Bearer) (context.Context, error) {
	return o.handleToken(ctx, t.Token, []string{})
}

func (o MySecurityHandler) HandleOAuth2(ctx context.Context, operationName string, t api.OAuth2) (context.Context, error) {
	return o.handleToken(ctx, t.Token, t.Scopes)
}

func (o MySecurityHandler) handleToken(ctx context.Context, jwtToken string, expectedClaims []string) (context.Context, error) {
	var userClaim UserClaim
	token, err := jwt.ParseWithClaims(jwtToken, &userClaim, func(token *jwt.Token) (any, error) {
		blockPub, _ := pem.Decode([]byte(jwtKey))
		return x509.ParsePKIXPublicKey(blockPub.Bytes)
	})
	if err != nil {
		return ctx, err
	}

	if !token.Valid {
		return ctx, errors.New("invalid token")
	}

	if err = checkTokenClaims(expectedClaims, userClaim); err != nil {
		return ctx, fmt.Errorf("token claims don't match: %w", err)
	}

  	// TODO その他、必要なチェックを実施

	return nil, nil
}

// checkTokenClaims はスコープのチェックを行う
func checkTokenClaims(expectedClaims []string, t UserClaim) error {
	// ...省略...
	return nil
}

上記の2つのハンドラーをmain.goで呼び出して完成です。

package main

import (
	"log"
	"net/http"

	"githu.com/ma91n/summer2024/ogensample/api"
)

func main() {
	srv, err := api.NewServer(&HelloHandler{}, MySecurityHandler{})
	if err != nil {
		log.Fatal(err)
	}

	if err := http.ListenAndServe(":8080", srv); err != nil {
		log.Fatal(err)
	}
}

go run . で実行すると、8080 ポートで起動します。

curl で実行して動作確認します。

$ curl localhost:8080/hello
{"message":"hello"}

$ make curl-bearer
curl -H "Authorization: Bearer <トークン>" localhost:8080/hello-bearer
{"message":"hello"}

$ curl -H "Authorization: Bearer <トークン>" localhost:8080/hello-oauth2
{"message":"hello"}

$ curl -H "Authorization: Bearer <トークン>" localhost:8080/hello-oidc
{"message":"hello"}

あえて失敗させるケースでの挙動を見てみます。

# Authorizationヘッダなしで動かすケース
$ curl localhost:8080/hello-bearer
{"error_message":"operation HelloBearer: security \"\": security requirement is not satisfied"}

# JWTのシグネチャを1文字書き換えたケース
$ curl -H "Authorization: Bearer <1文字シグネチャを書き換えた不正なトークン>" localhost:8080/hello-bearer
{"error_message":"operation HelloBearer: security \"Bearer\": token signature is invalid: crypto/ecdsa: verification error"}

詳細は割愛しますが、JWTトークンにユーザーIDなどが含まれており、各Handlerアプリ側で利用したい場合も、ctx に詰めて連携可能であり、使いやすインターフェース（フレームワーク）だと感じました。

ogenのサーバサイドコード生成について、まとめると次のような所感です。

• OIDCには対応していない
• Bearer、OAuth2といった種別ごとに一律、ミドルウェアのような形式で認可ロジックを実装する
• 各エンドポイント毎に挙動を変えたい場合は、引数のoperationIdの値を利用して切り替え可能
• Bearer、OAuth2で生成コードの差分はほぼ無いが、スコープフィールドだけが増える
• JWTトークンのパースや検証を自前で実装する
• JWTトークンの値を後続に引き渡したい場合は、 context.Context を経由する

2. oapi-codegen

ogenより先発だけあって、利用実績も多数なoapi-codegenですが、2024年5月にOrganizationがdeepmapからoapi-codegen に変わったようです。

セットアップです。

# インストール
go install github.com/deepmap/oapi-codegen/v2/cmd/oapi-codegen@v2.2.0

# コード生成
oapi-codegen --config=config.yaml openapi.yaml

oapi-codegen はEcho、Gin、net/http などに沿ったコードを生成できますが、今回は net/http 向けで出力します。また、リクエスト／レスポンスを構造体にマッピングまで行ってくれる、strict-server モードを有効にします。これを踏まえ、先程のコード生成コマンドの引数で渡していたconfig.yaml を以下のように設定しました。

package: api
generate:
  std-http-server: true
  models: true
  strict-server: true
  embedded-spec: true
output: api/gen.go

各エンドポイントは oapi-codegen が生成した api/gen.go の StrictServerInterfaceインターフェースを実装する必要があります。全体像は hello_handler.go を参照いただきたいですが、ref でオブエジェクト参照すると、ogenと比べ生成されたコードにネストが発生するところが、少しもどかしさを感じます。

type HelloServer struct{}

func (s HelloServer) Hello(_ context.Context, _ api.HelloRequestObject) (api.HelloResponseObject, error) {
	return api.Hello200JSONResponse{HelloJSONResponse: api.HelloJSONResponse{Message: ptr("hello")}}, nil
}

func (s HelloServer) HelloBearer(_ context.Context, _ api.HelloBearerRequestObject) (api.HelloBearerResponseObject, error) {
	return api.HelloBearer200JSONResponse{HelloJSONResponse: api.HelloJSONResponse{Message: ptr("hello")}}, nil
}

func (s HelloServer) HelloOAuth2(_ context.Context, _ api.HelloOAuth2RequestObject) (api.HelloOAuth2ResponseObject, error) {
	return api.HelloOAuth2200JSONResponse{HelloJSONResponse: api.HelloJSONResponse{Message: ptr("hello")}}, nil
}

認証部分は、ミドルウェアとして実装します。リポジトリ側にexamples実装があるため、それを参考にするとよいでしょう。RAEDMEの記載を見る限り、現状はミドルウェアで実装する必要があるが、将来的にはファーストクラスサポートしていくよとあり、期待です。

サンプル実装を元に main.go を実装します。ミドルウェアですが、nethttpmiddlewareというoapi-codegenが用意してくれたパッケージを利用します。

package main

// ...中略...

func main() {
	spec, err := api.GetSwagger()
	if err != nil {
		log.Fatalln("loading spec: ", err)
	}
	spec.Servers = nil

	// 認証処理はミドルウェアとして実装
	mw := nethttpmiddleware.OapiRequestValidatorWithOptions(spec,
		&nethttpmiddleware.Options{
			Options: openapi3filter.Options{
				AuthenticationFunc: NewAuthenticator(), // ★NewAuthenticatorは個別実装の部分
			},
		})

	strictHandler := api.NewStrictHandler(HelloServer{}, nil)
	h := api.HandlerFromMux(strictHandler, http.NewServeMux())

	s := &http.Server{
		Handler: mw(h),
		Addr:    "0.0.0.0:8080",
	}
	log.Fatal(s.ListenAndServe())
}

ミドルウェアの実体としては次のようなインターフェースを実装します。現時点ではセキュリティスキーマごちゃまぜですので、入力値でスイッチして切り替えます。openapi3filter.AuthenticationInput はopenapi.yaml の解析結果や http.Request も取れるため、やろうと思えばすべて判定できます。

func NewAuthenticator() openapi3filter.AuthenticationFunc {
	return func(ctx context.Context, input *openapi3filter.AuthenticationInput) error {
		securitySchemeName := input.SecuritySchemeName
		switch securitySchemeName {
		case "": // 認証なし
			return nil
		case "Bearer":
			return validateSecurityScheme(input)
		case "OAuth2":
			return validateSecurityScheme(input)
		case "OIDC":
			return validateSecurityScheme(input)
		default:
			panic("not supported security scheme " + securitySchemeName)
		}
	}
}

func validateSecurityScheme(input *openapi3filter.AuthenticationInput) error {
	jws, err := getJWSFromRequest(input.RequestValidationInput.Request)
	if err != nil {
		return fmt.Errorf("getting jws: %w", err)
	}

	var userClaim UserClaim
	token, err := jwt.ParseWithClaims(jws, &userClaim, func(token *jwt.Token) (any, error) {
		// 参考: https://stackoverflow.com/questions/21322182/how-to-store-ecdsa-private-key-in-go
		blockPub, _ := pem.Decode([]byte(jwtKey))
		return x509.ParsePKIXPublicKey(blockPub.Bytes)
	})
	if err != nil {
		return fmt.Errorf("validating JWS: %w", err)
	}

	// ...ここからはogen版と同様であるため省略...

	return nil
}

サーバを go run . で起動して、動作確認します。

$ curl localhost:8080/hello
{"message":"hello"}

$ make curl-bearer
curl -H "Authorization: Bearer <トークン>" localhost:8080/hello-bearer
{"message":"hello"}

$ curl -H "Authorization: Bearer <トークン>" localhost:8080/hello-oauth2
{"message":"hello"}

$ curl -H "Authorization: Bearer <トークン>" localhost:8080/hello-oidc
{"message":"hello"}

エラーメッセージはハンドリングがデフォルトのままなので、JSONではなく文字列が返ってきていますが、チェック自体はできていることがわかります。

# Authorizationヘッダなしで動かすケース
$ curl localhost:8080/hello-bearer
security requirements failed: getting jws: authorization header is missing

# JWTのシグネチャを1文字書き換えたケース
$ curl -H "Authorization: Bearer <1文字シグネチャを書き換えた不正なトークン>" localhost:8080/hello-bearer
security requirements failed: validating JWS: token is malformed: could not JSON decode header: invalid character '\x13' looking for beginning of value

oapi-codegenのサーバサイドコード生成について、まとめると次のような所感です。

• openapi.yaml の定義上でオブジェクトを $ref 参照させると少しコードが冗長に見える（回避策の有無は未調査）
• Bearer、OAuth2、OIDCのチェックは現時点ではミドルウェアで実装し、コード生成上のサポートは弱い（将来的に解消する方向とREADMEに記載あり）
• ミドルウェアでは、判定に必要な情報はすべて取得できるため、該当のリクエストがBearer、OAuth2、OIDCのどれでチェックすべきか、operationIdを用いた各エンドポイント固有の挙動を追加するなど柔軟に開発できる自由度がある
• 試していないが、JWTトークンを解析した結果は http.Request を取得できるため Request.WithContext() を用いた context.Context 経由で各エンドポイント側に渡すことが可能だと考えられる
• JWTトークンのパースどころか、リクエストヘッダから取得するところまで自前開発が必要（とはいえ、大したコード量にはならない）
• 様々な出力モードがあるため、検索結果が別の設定モードの場合があり、見極め力が必要な場合がある

3. openapi-generator

最も有名なコード生成ツールである openapi-generator を試します。様々な言語に対応していますが、記事の趣旨からGo言語かつサーバサイドに絞って生成します。

セットアップです。

# インストール
npm install @openapitools/openapi-generator-cli -g

# コード生成
openapi-generator-cli version-manager set 7.8.0

各エンドポイントのコードは生成されたopenapi/api_ping_service.go のTODOを埋めて実装します。DO NOT EDITを手動で消しつつ、 .openapi-generator-ignore に上記のパスを追加することで、上書きされることを防ぐ必要があります。

type PingAPIService struct {
}

func NewPingAPIService() *PingAPIService {
	return &PingAPIService{}
}

// Hello - hello👋
func (s *PingAPIService) Hello(_ context.Context) (ImplResponse, error) {
	return Response(http.StatusOK, Hello{Message: "Hello"}), nil
}

// HelloBearer - hello bearer👋
func (s *PingAPIService) HelloBearer(ctx context.Context) (ImplResponse, error) {
	return s.Hello(ctx)
}

// HelloOAuth2 - hello oauth2👋
func (s *PingAPIService) HelloOAuth2(ctx context.Context) (ImplResponse, error) {
	return s.Hello(ctx)
}

// HelloOIDC - hello openid connect👋
func (s *PingAPIService) HelloOIDC(ctx context.Context) (ImplResponse, error) {
	return s.Hello(ctx)
}

openapi-generator のGoサーバサイド生成ですが、セキュリティスキーマには未対応 です。generators/go-server.md にもその旨が書かれています。コード生成上の支援は現時点では受けられません。

そのため、認証処理はミドルウェアで個別実装する必要があります。デフォルトでは GitHub.com/gorilla/mux が利用される（chiに切り替えも可能）ので、muxのミドルウェアを実装します。

ミドルウェアとして、そのリクエストが認証なし・Bearer・OAuth2.0・OIDCかどうかは自分で判定する必要があります。また、該当のリクエストがどのスコープを要求するかも自分でマッピングを準備する必要があります。

func Authentication(next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		switch r.URL.Path {
		case "/hello":
			next.ServeHTTP(w, r)
		default: // URL＋HTTPメソッドごとに手動でマッピングするなどの必要がある
			if err := validateToken(r); err != nil {
				status := http.StatusUnauthorized
				_ = openapi.EncodeJSONResponse(map[string]any{"message": err.Error()}, &status, w)
				return
			}
			next.ServeHTTP(w, r)
		}
	})
}

func validateToken(r *http.Request) error {
	jws, err := getJWSFromRequest(r)
	if err != nil {
		return fmt.Errorf("getting jws: %w", err)
	}

	// ...ここからはoapi-codegenと同様なので省略...
 	// 認可スコープの引き渡しも自前でなんとかする必要がある

	return nil
}

マッピング情報を oepnapi.yaml とダブルメンテすることは実運用上、耐えられないチームが多いと思いますのでそのままでは利用できないという判断を下すことが多いかなと思います。そのため、Yusuke ItoさんのZennブック【Go言語】OpenAPI Generatorを使いこなすスキーマ駆動開発 にある通り、テンプレートがmustacheで書かれており、これを拡張して利用するといった取り組みが必要となるかと思います。

openapi-generator のサーバサイドコード生成について、まとめると次のような所感です。

• 記事には書いていなかったが、.openapi-generator、.openapi-generator-ignore、openapitools.json、README.md などGoのコード以外にもファイルが生成して初見は少し驚く
• 各エンドポイントの実装は迷うことが少ないが、ImplResponseのボディは interface{} であるため、型がふわっとしてしまって残念に感じた（回避方法の有無は未調査）
• 認可周りのコード生成上の支援が無く、使いこなすにはテンプレートをカスタマイズする勢いが必要そう
• Yusuke ItoさんのZennブック[【Go言語】OpenAPI Generatorを使いこなすスキーマ駆動開発]によれば、カスタマイズしたテンプレート実行には、Java環境（Mavenなど）が必要で、メンバーのスキルセット次第では障壁がある（FAT JAR提供とかあったらすいません）
• 調査すると、他の言語（Swiftなど）の結果が出てくるので、検索ワード力が必要かもしれない

さいごに

OpenAPI 3系かつGoのサーバサイドコード生成に対応した ogen・oapi-codegen・openapi-generatorについて、Bearer・OAuth2.0・OIDC認可でどのようにコード生成が対応しているか試しました。現時点では ogen が後発だけあって一番垢抜けていて、oapi-codegenも十分に扱いやすい。openapi-generatorは玄人向けだなと感じました。

コード生成上はサーバサイドに限ると、Bearer・OAuth2.0・OIDCで変化はほぼ無いため（大半はミドルウェア的に実装するだけ）であるため、サーバサイドの実装視点では openapi.yaml で細かく定義する意味はあまり無い（もちろんWeb APIの利用者視点では有意義な手がかりになるでしょうが）という結果でした。

近い将来では、これらコードジェネレータの領域は、ChatGPTとかclaude.aiに openapi.yaml を入力させてプロンプトエンジニアリングでコード生成させる方向でも広がっていくと良いかなと思っています。コード生成コマンド時のオプションや、設定ファイルなどで行う微調整的な機能は、生成AI側で行ってくれる未来…、来ると良いなぁ。

Microsoft 365 Developer Programのウェブサイトで上のメニューのDeveloper Programの「My Dashboard」を選びます。この遷移がわからなくていつもJoin Nowをしていました。

こちらがダッシュボードです。

ここでGo to subscritpionを選択すると、次のオフィスのポータルっぽいページに移動します。

左のツールバーのAdminアイコンをクリックして・・・上のツールバーにentraidを入れて検索して出てくるIdentityがEntraIDです。

前提

Entra IDを組み込む方法については以前のエントリーで紹介しています。

• MSAL.jsを使ってウェブフロントエンドだけでAzureAD認証する
• AzureAD＋MSAL for Goでバッチコマンドの認証

後者は他の認証基盤でもだいたい同じですが、前者は、MSAL.jsのおかげでフロントエンドのみで認証が完了するということを紹介しました。多くの場合はサーバーにもコールバックがきたりとか、サーバーもログイン処理の一部に入っているのですが、そこが不要となっています。そのため、バックエンドとしては有効なJWTがリクエストについてきて、その署名の検証だけすればOKという状態となっています。

問題はその署名入りのJWTトークンをどうつくるか、という一点に絞られます。

ちなみに、JWTのTがトークンでJWTトークンと書くと「JSONウェブトークン・トークン」となってしまうのですが、毎回JWTをロングで書くのも面倒ですし、JWTだけだと不親切かと思いますJWTトークンにしています。江戸川や利根川を英語に翻訳するときに「エドガワーリバー」とか「トネガワリバー」とかになるのと同じようなものだと思っていただければ。

自前で署名とJWTトークンを作る

Entra IDの場合、 https://login.microsoftonline.com/{テナントID}/v2.0/.well-known/openid-configuration にアクセスし、その中の jwks_uriというキーを見ると、署名検証のためのJWKの公開鍵が手に入ります。おそらくはhttps://login.microsoftonline.com/{テナントID}/discovery/v2.0/keysというURLのはずですが。ですが、この公開鍵はEntra IDが内部で保持している秘密鍵を使った署名の検証にしか使えないため、テスト用のJWTトークンを作る場合はこの鍵は使えません。そのため、まずはローカルの公開鍵と暗号鍵のペアを作ります。以下のサイトを使うのが簡単でしょう。

• https://mkjwk.org/

RSAタブを開き以下のように入れるとEntra IDっぽくなります。KeyIDは任意です。

• Key Size(鍵のビット数): 2048
• Key Use(鍵の用途): Signature
• Algorithm(アルゴリズム): RS256
• Key ID(鍵の識別子): “for test”
• Show X.509(): No

生成されたら、一番左と一番右をそれぞれJWTトークン作成用に保存しておきます。真ん中はサーバーで利用するのに便利な情報なのでこれも保存しておきます。

JWTトークンを作成

次にJWTを作ります。テナントIDとアプリケーションIDはテスト環境のEntraIDで生成したものと同じものを使う、あるいは独自に作るでもどちらでもよいですが決めておきます。UUIDの型式です。このサンプルではテナントIDを0000000-0000-0000-0000-000000000000、アプリケーションIDを1111111-1111-1111-1111-111111111111とします。

Entra ID相当のトークンを作りたいので、こんな感じのclaimを用意します。重要な項目は以下の通りです。

• tid: テナントIDとする
• aud: クライアントID＝アプリケーションID
• iss: https://login.microsoftonline.com/(テナントID)/v2.0
• exp: 有効日時(2035年にしてある)
• iat/nbf: ログイン日時
• exp: 有効期限
• sub: ユーザーのキー

{
  "aud": "1111111-1111-1111-1111-111111111111",
  "iss": "https://login.microsoftonline.com/0000000-0000-0000-0000-000000000000/v2.0",
  "iat": 1671015703,
  "nbf": 1671015703,
  "exp": 2071019603,
  "idp": "https://sts.windows.net/3eca0868-d511-4342-8659-e88a2e3bf9fe/",
  "name": "Test User(テストユーザー)",
  "nonce": "ce3fd167-0e5a-43ae-bb8b-11d8d003d8c6",
  "oid": "daf6a6c6-d549-4421-bf71-3b59fd74d531",
  "preferred_username": "test.user@example.co.jp",
  "rh": "0.AWoA733wxZg0tkymktoZGQzOJ_1Ryon2gERMsUs1n-XnFcpqAFQ.",
  "sub": "oXxd31705vfpTnrSPcdVCdAoalq7ZgQ_gx7Msq7OBzY",
  "tid": "0000000-0000-0000-0000-000000000000",
  "uti": "Fw7ZoF0z1UCipEF8hfwZAA",
  "ver": "2.0"
}

subはユーザーを表すユニークなキーとされていますが、Entra ID上のこのsubと、実際のシステム上のユーザーの対応付けは別途決めておく必要があります。Entra IDとHRのシステムの同期をきちんととっておくのであればこのsubを使ってユーザーを決められますが、そうでない場合はマニフェストを変更してユーザーコード相当の情報を登録したり、preferred_usernameを使うといったことが必要になります。そのあたりはサーバー側の方針に合わせて上記のclaimは修正してください。

次にjwt.ioを開きます。

https://jwt.io/

アルゴリズムをRS256に変更し、PAYLOADに上記のclaimを、その下の署名欄の上の公開鍵にはmkjwk.orgで作った公開鍵を、その下の秘密鍵にはmkjwk.orgで作った秘密鍵を貼り付けます。

これで左側にJWTが生成されます。

これはmkjws.orgで作成したjwks.orgの証明書を使って署名の確認が行えます。サーバー側でJWTトークンを検証するときは、Entra IDの秘密鍵ではなく、mkjwk.orgで生成した秘密鍵（真ん中のPublic and Private Keypair Setが同じ形式なので扱いやすい）を使って署名の検証が行えます。任意のユーザー情報を作ってトークンを量産できますし、実際のログインは不要なのでテストでも扱いやすいでしょう。このトークンを使えばcurlでもなんでも自由にリクエストが飛ばせるようになります。

https://future-architect.github.io/articles/20220902a/

テストにおいては、モックは使うものの、モックを差し込むレイヤーはソースコードレベルではなくて、インフラレベルで仕掛ける方がいいよ、というのはほぼコンセンサスとなっていると思います。

• RDBを使うには、DockerでさっとPostgreSQLを差し込む
• フロントエンドからのHTTPの外部サービスを使うには、Mock Service WorkerとかCypressのinterceptを使う

もちろん、フレームワークでH2とかSQLiteとかのローカルで簡単に使えるDBMSをサポートしているならそれを使うのも手ですが、ともかく、コードレベルのモックオブジェクトを実装するのはなし、という感じですね。

というのも、やり方を間違えると、モックに対するテストコードになって、コード量のわりに品質があがらないとか、結局実システムの挙動の変化に気づけずに不具合が防止できないとか、モックをコードで作るのはあまりよくないという論調ですね。なるべく上流でモックすれば、そのような問題は減ります。将来的にはモックの挙動が正しいかの検証とかそういうあたりの進化もあるかな、と思いつつ、楽に成果が出るならそちらを今は選択すべきと思います。

メールを送信するシステムにおいても、MailSlurperを使えば良さそうなので試してみました。最近よく見かける、6桁の数字のコードで追加認証するシステムのテストです。

MailSlurper

MailSlurperは、MITライセンスのオープンソースのメールサーバー兼クライアントです。SMTPでメールを受けることができて、ブラウザでそのメールを確認できます。また、REST APIも提供されており、受信したメールをAPIで取り出せます。Go製で軽く、Dockerで気軽に起動できます。

メールボックスは1つで、来たメールはすべて一か所に集まります。ドキュメントを見ると、クライアント証明書をアクセス時に必要という設定ができ、本番環境でも使うことを想定してそうです。ただ、エンドユーザー向けに使うにもメールボックスが1つしかないと不便ですし、受信後のイベント起動とかがないので、バックエンド処理のトリガーにするにも少し心もとありません。今のところはテスト用途がベストかな、と思っています。

GitHubを見てもここしばらくはあまり更新されていないのですが、SMTPは機能的には枯れているので問題ないでしょう。

6桁の数値の生成とセキュリティ

みなさん、Real World HTTPはすでにご覧になられていると思いますので、お手元の本の「14.8.5　タイムベースワンタイムパスワードアルゴリズム（TOTP）」を見れば詳しいことが書かれているので、詳細については語りませんが、秘密鍵として用意したシークレットをもとに、日時情報を加えて6桁の数値を生成します。Goなら github.com/pquerna/otp/totp パッケージを利用するのが簡単です。

6桁の数値の計算はRFCで決められたアルゴリズムに基づいて行います。高いセキュリティが求められるようなサービスであれば、事前に秘密鍵をGoogle Authenticatorなどのアプリに登録しておき、TOTPのアルゴリズムに従って出力した数値をサーバーに送り、サーバー側でも同じ計算をすることで照合します。秘密鍵そのものは最初の登録時以外はネットワークを流れることがないため、通信経路が安全でなくても比較的安全です。仮に通信が傍受されても、そのコードは30秒（たいていのサービスの場合）しか有効でないからです。

一方で、あまりプロ向けのサービス出ない場合は、同じTOTPのアルゴリズムであっても、別の使い方をします。登録されているメールアドレスやSMS、音声通話で6桁のコードをユーザーに伝え、それをユーザーがサーバー画面で入力して戻すことで照合します。通信経路の傍受に対する強度は同じですが、仮にSIMスワップ攻撃を受けたり、メールサーバーのアカウントがクラックされてアクセスされてしまうと突破できてしまうので、手元のハードウェアに触られなければ安心の前述の方法よりはやや安全性は落ちます（もちろん、秘密鍵をそのデバイスにしか入れていないという前提で）。

後者のような機能を実装するサービスは増えているので、それをMailSlurperを使ってテストしてみます。

シークレットの作成

シークレットの生成は github.com/pquerna/otp で簡単にできます。シークレット生成はユーザー登録時に行い、サーバー側でユーザーごとに保存します。後半のコードは、すでに登録済みのユーザーに対して行う前提なので、あらかじめ作っておいてテストコードに利用します。登録プロセスを実装する場合はこちらのコードを参考にしてください。

package main

import (
	"fmt"
    "log"

	"github.com/pquerna/otp/totp"
)

func main() {
    key, err := totp.Generate(totp.GenerateOpts{})
    if err != nil {
        log.Fatal(err)
    }
    fmt.Printf("key: %s\n", key.Secret())
}

テストサーバーの起動

テストのためのMailSlurperを起動しておきます。docker composeを利用します。ウェブの管理画面、API、SMTPポートの3つを開けておきます。なお、公式のDockerイメージはなく、野良イメージが多いのですが、marcopas/docker-mailslurper が一番ドキュメントが充実しています。

services:
  mailslurper:
    image: marcopas/docker-mailslurper:latest
    ports:
      - '8080:8080' # web UI
      - '8085:8085' # API
      - '2500:2500' # smtp

あとは起動するだけです。 http://localhost:8080 にアクセスして管理画面にアクセスできることを確認しましょう。

docker compose up

テストコード作成

これから作るコードは、6桁の認証コードつきのメールを送信するものです。その6桁の数値が正しいものかどうかの検証を来ないます。

MailSlurperはREST APIを提供しています。送信されたメール一覧を取得してきます。取得にあたっては、送信もとアドレスや送信先のアドレスでフィルタリングもできます。

まずはテストヘルパーとして、メールサーバーからメールをとってくるコードを作成してみます。6桁の数値を取り出します。送信先アドレスでフィルタリングを行うようにします。同時にテストを並行で走らせたとしても、送信先のユーザー（アドレス）を分けておけばテストが干渉することがなくなります。今回はGoで実装しています。

package authcode

import (
	"encoding/json"
	"net/http"
	"net/url"
	"regexp"
	"strings"
	"testing"
)

// json2goで作成した、MailSlurperのメールアドレス一覧のレスポンス
type MailSlurperResponse struct {
	MailItems    []MailItem `json:"mailItems"`
	TotalPages   int        `json:"totalPages"`
	TotalRecords int        `json:"totalRecords"`
}

type MailItem struct {
	ID          string   `json:"id"`
	DateSent    string   `json:"dateSent"`
	FromAddress string   `json:"fromAddress"`
	ToAddresses []string `json:"toAddresses"`
	Subject     string   `json:"subject"`
	Body        string   `json:"body"`
}

// toアドレスでフィルタリングしてのメールの取り出し
func ReceiveMail(t *testing.T, host, to string) []MailItem {
	t.Helper()
	u, err := url.Parse(host)
	if err != nil {
		panic(err)
	}
	u.Path = "/mail"
	q := url.Values{}
	q.Set("to", to)
	u.RawQuery = q.Encode()

	res, err := http.Get(u.String())
	if err != nil {
		panic(err)
	}
	defer res.Body.Close()
	d := json.NewDecoder(res.Body)
	r := MailSlurperResponse{}
	err = d.Decode(&r)
	if err != nil {
		panic(err)
	}
	return r.MailItems
}

// 6桁のコードを取り出す（裏でメールサーバーから情報取得）
func ReceivePassCode(t *testing.T, host, to string) string {
	t.Helper()
	mails := ReceiveMail(t, host, to)

	p := regexp.MustCompile(`\d{6}`)

	for _, m := range mails {
		return p.FindString(m.Body)
	}
	return ""
}

完成したテストコードは以下の通りです。短く書けますね。

package authcode

import (
	"os"
	"testing"
)

func TestValidate(t *testing.T) {
	secret := "LB6BHGYD63JCWM4BBPHCSRBXGZYKGDI3" // 事前に作成しておいたシークレット
    // これから作成する、パスコード送信処理
	err := SendPassCode("localhost:2500", "test user", "test@example.com", secret)
	if err != nil {
		t.Errorf("error should be nil: %v", err)
		return
	}

	code := ReceivePassCode(t, "http://localhost:8085", "test@example.com")
    // これから実装するバリデーション
	if !Validate(code, secret) {
		t.Error("validation failed")
	}
}

APIエンドポイントの/mailにtoクエリーをつけて帰ってくるJSONをいじるだけなので、他の言語でもすぐに実装できると思います。

コード生成とメール送信

登録済みのユーザー（サーバーは、名前、メールアドレスおよび、シークレットを知っている）に対して、コードを生成して送信します。なお、レガシーなもろもろの塊であるメールで日本語を正しく送信するにあたっては、以下のQiita記事を参考にしました。

• go で utf8メールを送信

上記のテストが通るように実装したのが以下のテストです。

package authcode

import (
	"bytes"
	"encoding/base64"
	"net/mail"
	"net/smtp"
	"strings"
	"time"

	"github.com/pquerna/otp/totp"
)

// 上記のエントリーから、add76crlf, utf8Split, encodeSubjectをコピーしておくこと

// メールの作成
func GenerateMessage(toUserName, toAddress, secret string) ([]byte, error) {
	from := mail.Address{"Myサービス", "noreply@my-service.com"}
	to := mail.Address{toUserName, toAddress}

	var msg bytes.Buffer
	msg.WriteString("From: " + from.String() + "\r\n")
	msg.WriteString("To: " + to.String() + "\r\n")
	msg.WriteString(encodeSubject("Myサービスの認証コード"))
	msg.WriteString("MIME-Version: 1.0\r\n")
	msg.WriteString("Content-Type: text/plain; charset=\"utf-8\"\r\n")
	msg.WriteString("Content-Transfer-Encoding: base64\r\n")

	code, err := totp.GenerateCode(secret, time.Now())
	if err != nil {
		return nil, err
	}

	var body bytes.Buffer
	body.WriteString("認証コードはこちらです\n\n" + code + "\n\nMyサービス")
	msg.WriteString("\r\n")
	msg.WriteString(add76crlf(base64.StdEncoding.EncodeToString(body.Bytes())))

	return msg.Bytes(), nil
}

// メール送信
func SendPassCode(host, toUserName, toAddress, secret string) error {
	msg, err := GenerateMessage(toUserName, toAddress, secret)
	if err != nil {
		return err
	}
	err = smtp.SendMail(
		host,
		nil,
		"noreply@my-service.com",
		[]string{toAddress},
		msg,
	)
	return err
}

// クライアントに送信されたパスコードのバリデーションを行う
func Validate(passcode, secret string) bool {
	return totp.Validate(passcode, secret)
}

先ほどのテストに対して実行すると、正しくテストをパスします。簡単にメール送信を伴うコードのテストができました。

テストの後始末

テストを行い続けると、メールボックスにメールが溜まり続けます。リソースを消費する量は大したことがないとはいえ、増え続けるのは精神衛生上良くないです。幸い、MailSlurperはメールボックスのリセットもAPIで提供してくれていますので、それを使ってみます。

まずは先ほどのテストヘルパーのファイルに以下のメールボックスリセットを送信するヘルパー関数を追加します。

func ResetMailSlumper(host string) {
	u, err := url.Parse(host)
	if err != nil {
		panic(err)
	}
	u.Path = "/mail"

	req, _ := http.NewRequest("DELETE", u.String(), strings.NewReader(`{"pruneCode": "all"}`))
	req.Header.Set("Content-Type", "application/json")
	http.DefaultClient.Do(req)
}

テストの実行前にリセットを呼ぶようにします。後始末だと、実行後の方が自然に思えるかもしれませんが、テストのリソースのリセットを後にしてしまうと、問題発生時に結果を追いかけるのが大変になるため、僕は全体の実行前にクリアするようにしています。

func TestMain(m *testing.M) {
	ResetMailSlumper("http://localhost:8085")
	code := m.Run()
	os.Exit(code)
}

まとめ

これで実SMTPサーバーを使ったコードを書いて、それをMailSlurperを使ってテストする方法を学びました。REST APIのおかげで、ヘルパーさえ用意してしまえば、テストを書くのは簡単です。

これだけ使いやすいとなると、非同期通信系は全部SMTPに寄せたくなってくる気もします。まあ本番環境の安定稼働を考えると実際にやることはないですが、MailSlurperは送信結果を見るのもできて、開発体験はかなり良いです。

明けましておめでとうございます！ Future筋肉エンジニアの渡邉です。年も明けたことなので切り替えて減量に入りました。三月末までを目安に体を絞ろうと思っています。

私は現在Google Cloudを利用しているプロジェクトに所属しており、Google Cloudのスキルアップにいそしんでいます。今回はGKE (Google Kubernetes Engine)でCloud IAP (Identity-Aware Proxy)を利用したWebアプリケーションのGoogleアカウント認証について記事を書こうと思います。

Identity-Aware Proxyとは

以下、公式ドキュメント引用

IAP を使用すると、HTTPS によってアクセスされるアプリケーションの一元的な承認レイヤを確立できるため、ネットワーク レベルのファイアウォールに頼らずに、アプリケーション レベルのアクセス制御モデルを使用できます。

簡単に言うとGoogleアカウントとCloud IAMの仕組みを用いてWebアプリケーションの認証をできます。

認証・承認フロー

公式ドキュメントはこちら

• Google Cloudリソースへのリクエスト(Cloud Load Balancing)します。
• IAPが有効になっている場合は、IAP認証サーバへ情報を送信します（プロジェクト番号、リクエストURL、リクエストヘッダー、Cookie内のIAP認証情報など）
• IAP認証サーバがブラウザの認証情報をチェックします。
• 認証情報が存在しない場合は、OAuth2.0のGoogleアカウントログインフローにリダイレクトし、認証確認を実施する。認証トークンは今後のアクセスのためブラウザのCookieに保存されます。
• 認証情報が有効な場合、認証サーバは認証情報からユーザのID（メールアドレスとユーザID）を取得します。
• 認証サーバはこのIDからユーザのIAMロールをチェックし、ユーザがリソースにアクセスできる権限(IAP で保護されたウェブアプリ ユーザー)を持っているかをチェックします
• 権限を持っていれば、アクセスOKになり、なければNGになります。

全体アーキテクチャ図

以下が全体アーキテクチャ図になります。
GKE/NetworkなどのGoogle Cloudのリソース構築に関しては慣れ親しんでいるTerraformを利用して作成しました。OAuth同意画面に関しては外部公開する場合は、APIから作成できない (公式ドキュメント記載)ので、コンソール画面から設定しました。

Bastion初期設定

Public Subnetに作成したGCEインスタンスからGKEのコントロールプレーンに対してkubectlコマンドを実行したいので、
kubectlコマンドや、google-cloud-sdk-gke-gcloud-auth-pluginなどをインストールします。
以下、Bashスクリプトです。

#!/bin/bash

########################################################
# Author: watanabe
# Initial Date: 2022/12/28
# History: Create
########################################################

# Variable Definition
project_name="xxxxxxxxxx"
gke_cluster_name="xxxxxxxxx"
region="asia-northeast1"

# Install Kubectl
curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl"
chmod +x ./kubectl
sudo mv ./kubectl /usr/local/bin/kubectl
kubectl version

# Install google-cloud-sdk-gke-gcloud-auth-plugin
sudo apt-get install apt-transport-https ca-certificates gnupg
echo "deb [signed-by=/usr/share/keyrings/cloud.google.gpg] https://packages.cloud.google.com/apt cloud-sdk main" | sudo tee -a /etc/apt/sources.list.d/google-cloud-sdk.list
curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key --keyring /usr/share/keyrings/cloud.google.gpg add -
sudo apt-get update && sudo apt-get install google-cloud-cli
sudo apt-get install google-cloud-sdk-gke-gcloud-auth-plugin
gke-gcloud-auth-plugin --version
export USE_GKE_GCLOUD_AUTH_PLUGIN=True
source ~/.bashrc

# Get Credentials
gcloud container clusters get-credentials "${gke_cluster_name}" --region "${region}" --project "${project_name}"
kubectl config get-contexts
kubectl get node

manifestファイル

また、manifestファイルは以下を用意してkubectlコマンドを実行しk8sリソースをGKEに対して作成しました。

ここまでの設定で事前準備は完了です。

Deployment

nginxのPodを用意するため、Deploymentのmanifestを作成しました。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.22
        ports:
        - containerPort: 80

Service

IngressにはNodePortが必要になるので、Serviceのmanifestを作成しました。

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  type: NodePort
  selector:
    app: nginx
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP

ManagedCertificate

クライアントとIngressで構築するHTTP(S)ロードバランサ間をHTTPSでアクセスするようにしたいので、Googleマネージド証明書のmanifestを作成しました。
domainsには、terraformで用意したHTTP(S)ロードバランサに設定したい外部IPアドレスにフリーなワイルドカードDNSサービスのnip.ioを利用したものを設定します。

apiVersion: networking.gke.io/v1
kind: ManagedCertificate
metadata:
  name: nginx
spec:
  domains:
    - 34.xxx.xxx.xxx.nip.io

Ingress

インターネット上にnginxを公開するためにIngressを構築するmanifestを作成しました。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-ingress
  annotations:
    # 外部ロードバランサの作成
    kubernetes.io/ingress.class: "gce"
    # クライアントとHTTP(S)ロードバランサ間のすべての通信をHTTPSに強制
    kubernetes.io/ingress.allow-http: "false"
    # 事前に用意していた静的外部IPアドレスを設定する
    kubernetes.io/ingress.global-static-ip-name: "loadbalancer-external-ip-address"
    # Googleマネージド証明書をIngressに適用する
    networking.gke.io/managed-certificates: "nginx"
spec:
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: nginx-service
            port:
              number: 80

Cloud IAPなしでのアクセス確認

まず、Cloud IAPなしでのアクセス確認を行います。
Load Balancerに設定したドメインに対してアクセスを行うと、特に認証画面を経由することもなくアクセスできます。

Cloud IAPの設定を追加

上記の状態ではだれでもアクセスできるため、セキュアな状態ではありません。
ここでCloud IAPの設定を追加してみましょう。

OAuth同意画面の作成

OAuth同意画面はUser Typeを「外部」で作成します。

アプリ情報として、必須項目の以下を設定して「保存して次へ」をクリックします。
ほかの情報は任意のため設定しませんでした。

• アプリ名：GKE Application
• ユーザサポートメール：自身のメールアドレス
• デベロッパーの連絡先情報：自身のメールアドレス

スコープとテストユーザは任意情報のため設定しませんでした。
以下が設定完了したOAuth同意画面になります。

OAuth認証情報の作成

APIとサービスタブの「認証情報」をクリックします。
認証情報の作成プルダウンリストからOAuthクライアントIDをクリックします。

• アプリケーションの種類：ウェブアプリケーション
• OAuthクライアントIDの名前：GKE Application
  を入力し、作成ボタンをクリックします。

作成ボタンをクリックするとOAuthクライアントIDとクライアントシークレットが生成されるので、JSONをダウンロードします。

作成したOAuthクライアントを再度クリックし、承認済みリダイレクトURIをダウンロードしたOAuthクライアントID(CLIENT_ID)に修正して保存します。

https://iap.googleapis.com/v1/oauth/clientIds/CLIENT_ID:handleRedirect

IAPアクセス権の設定

Google Cloud ConsoleのIdentity-Aware Proxyにアクセスします。
アクセス権を付与するリソースの横にあるチェックボックスをオンにします。

IAPの有効化で「構成要件」を参照し、問題なければ「有効にする」をクリックします。

チェックボックスが「オン」になりました
右側のパネルから、「プリンシパルの追加」をクリックします。

IAPアクセスを許可したいGoogleアカウント（メールアドレス）または、Googleグループなどを指定して、IAMロール（IAP-secured Web App User）を付与してください。

ここまででOAuthの設定は完了です。

Kubernetes Secretの作成

GKEでCloud IAPを適用するためには、Kubernetes Secretを作成してBackendConfigに適用する必要があります。
先ほど作成してダウンロードしたOAuth認証情報のClient IDとClient Secretを指定してKubernetes Secretを作成します。

kubectl create secret generic oauth-secret --from-literal=client_id=xxxxxxxxxxxxxxxxxxxx.apps.googleusercontent.com \
    --from-literal=client_secret=xxxxxxxxxxxxxxxxxxxxxxxxx

Kubernetes Secretが作成されていることを確認します。

xxxxxxxxxxxxx@tky-bastion:~$ kubectl describe secret oauth-secret
Name:         oauth-secret
Namespace:    default
Labels:       <none>
Annotations:  <none>

Type:  Opaque

Data
====
client_secret:  35 bytes
client_id:      73 bytes

BackendConfigの作成

Kubernetes Secretで作成したSecretをBackendConfigに設定することでCloud IAPを適用できます。
以下のmanifestファイルを用意します。

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: iap-conifg
  namespace: default
spec:
  iap:
    enabled: true
    oauthclientCredentials:
      secretName: oauth-secret

kubectlコマンドでBackendConfigを作成します。

kubectl apply -f backendconfig.yaml

BackendConfigが作成されていることを確認します。

xxxxxxxxxxxxx@tky-bastion:~/manifest$ kubectl get backendconfig
NAME         AGE
iap-conifg   3m42s

サービスポートを BackendConfig に関連付けて、IAP の有効化をトリガーする必要があります。既存のService リソースにアノテーションを追加し、サービスのすべてのポートをデフォルトで BackendConfig にします。

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
# 追記
  annotations:
    beta.cloud.google.com/backend-config: '{"default": "config-default"}'
spec:
  type: NodePort
  selector:
    app: nginx
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP

kubectl apply -f service.yaml

以上で、Cloud IAPの設定は完了です。

Cloud IAPありでのアクセス確認

Cloud IAPの設定が完了したので、画面にアクセスしてCloud IAPが適用されているかを確認します。

Cloud IAP認証対象外アカウントでのアクセス確認

Load Balancerに設定したドメインに対してアクセスを行うと、Cloud IAPによるGoogleアカウントログイン画面にリダイレクトされます。

本GoogleアカウントはCloud IAPのアクセスできる権限(IAP で保護されたウェブアプリ ユーザー)を持っていないため、画面にアクセスできません。

Cloud IAP認証対象アカウントでのアクセス確認

Load Balancerに設定したドメインに対してアクセスを行うと、Cloud IAPによるGoogleアカウントログイン画面にリダイレクトされます。

本GoogleアカウントはCloud IAPのアクセスできる権限(IAP で保護されたウェブアプリ ユーザー)を持っているため、画面にアクセスできました。

さいごに

今回はGKE (Google Kubernetes Engine)でCloud IAP (Identity-Aware Proxy)を利用したGoogleアカウント認証について記事を書きました。
Google Cloudを利用していて、特定のGoogleアカウントにのみアクセスを許可したいケースはあるかと思いますので、その時にでも参考にしていただければ幸いです。

MSAL.jsはとても便利なライブラリです。前に書いたエントリーで説明しましたが、AzureAD側の設定は必要ですが、コードへの組み込みもすぐです。コールバックを受けるバックエンドサーバーの用意も不要で、フロントエンドだけで認証が完結します。

• https://future-architect.github.io/articles/20221118a/

ですが、開発時にAzureADがない場合もありますし、開発者全員が開発で使うAzureADにユーザー登録されていないかもしれません。また、権限ごとにいろんなユーザーを用意してテストできるようにしたいとかのニーズもあると思います。E2Eテストで毎回認証をすると遅いとか、コールバックを受けるコードがGitHub Actionsではうまく動かず実AzureAD認証を組み込むのが難しいとか、認証をスキップしたいニーズもいろいろあるため、開発時にはMSAL.jsをスキップできるようにしてみます。

設定の外だし

前回はハードコードしましたが、AzureADの接続情報などは.envで設定を流し込むべきですので、別ファイルに切り出します。各フレームワークごとに、ブラウザに環境変数を公開するには、キーの名前のルールがあります。Vue.jsであればVUE_APP_を前につけますし、Vite.jsだとVITE_をつけますし、Next.jsだとNEXT_PUBLIC_ですね。これらの設定はサーバーではなくてフロントエンド側なので、それらのルールに従った名前にします。Vue.jsだったら次の通り。

VUE_APP_AZURE_DUMMY_USER=dummy-user@example.com
VUE_APP_AZURE_ISSUER=https://login.microsoftonline.com/${テナントID},
VUE_APP_AZURE_APP_ID=${アプリケーションID}

これらの設定を使うようにします。コールバックのURLは現在実行中のホストの/callbackを向くように動的にパスを作っています。このパスをAzureAD側の設定にも入れる想定です。

import type { Configuration } from "@azure/msal-browser";

export const config: Configuration = {
    auth: {
        authority: process.env.VUE_APP_AZURE_ISSUER,
        clientId: process.env.VUE_APP_AZURE_APP_ID,
        redirectUri: `${location.protocol}//${location.host}/callback`
    },
    cache: {
        cacheLocation: "localStorage",
        storeAuthStateInCookie: false,
    }
};

テストユーザー対応

MSAL.jsを使うと、AzureADで認証してJWTトークンを作って返してくれます。それをそのままサーバーにも渡し、サーバー側でIDを取り出して使います。開発用モードを作るとして大幅なif分岐などは作りたくはないですよね？

• ダミーのJWTは作り、IDが分かるようにする
• ただしAzureADの証明書での署名はできないので、署名の確認はサーバーではあきらめる

AzureADのトークンを使う場合

今回は開発用のテストユーザーを環境変数から設定できるようにします。

VUE_APP_AZURE_DUMMY_USER=dummy-user@example.com

ブラウザ上でダミーのJWTを作るためにjoseパッケージを使います。これはブラウザで使えますが、npmパッケージのほとんどはNode.jsの機能を使っていてブラウザで使えないものが多かったです。

npm install jose

前回と違うところを主にサンプルとして提示しています。

ログインではダミーユーザーがあるかどうかで条件判断し、ダミーユーザーがいたらJWTを作って返しています。内容はだいたいAzureADが作っているものに似せるようにはしています（完全ではない）。

AzureADのトークンはsubではUUIDのようなコードが入っています。おそらくサーバー側でログインしたユーザーのIDをもとに権限管理をしたりするのであれば、preferred_usernameに入っているメールアドレスを使うことになるんじゃないかと思います。AzureAD側の設定でIDトークンに入れるクレームを増やして、emailクレームを足したりもできるようです。

// 追加
import { UnsecuredJWT } from 'jose'

// 前回はaccessTokenだったがidTokenに変更
let idToken = "";

// 前回のloginメソッドの修正
async login () {
  if (process.env.VUE_APP_AZURE_DUMMY_USER) { // ダミーユーザーモード
    const jwt = await new UnsecuredJWT({
      idp: 'https://sts.windows.net/....',
      name: 'Dummy User(ダミー ユーザー)',
      preferred_username: process.env.VUE_APP_AZURE_DUMMY_USER,
      sub: btoa(process.env.VUE_APP_AZURE_DUMMY_USER), // ナチュラルキーっぽくする
      ver: '2.0'
    })
      .setIssuer(`${process.env.VUE_APP_AZURE_ISSUER}/v2.0`)
      .setAudience(process.env.VUE_APP_AZURE_APP_ID)
      .setIssuedAt()
      .setExpirationTime('1h')
      .setNotBefore(Date.now() / 1000)
      .encode()
    idToken = jwt
  } else { // 本番モード
    if (_auth.getAllAccounts().length > 0) {
      _auth.setActiveAccount(_auth.getAllAccounts()[0])
      const result = await _auth.acquireTokenSilent({
        scopes: [`${process.env.VUE_APP_AZURE_APP_ID}/.default`],
        redirectUri: config.auth.redirectUri
      })
      idToken = result.idToken
      return idToken
    } else {
      return _auth.acquireTokenRedirect({
        redirectStartPage: location.href,
        scopes: [`${process.env.VUE_APP_AZURE_APP_ID}/.default`],
        redirectUri: config.auth.redirectUri
      })
    }
  }
},
async logout() {
  if (!process.env.AZURE_DUMMY_USER) {
    return _auth.logoutRedirect({
      postLogoutRedirectUri: `${location.protocol}//${location.host}/`
    })
  }
}

これで、AzureADがあるふりをしてそれっぽいIDトークンを作って返すコードができました。

サーバー側ではリクエストを受けるときにこのトークンを受けることになります。サーバー側も環境変数で少し動作をコントロールして、テストモードの時には署名の検証は行わない必要がありますが、expiration time(exp)、not before(nbf)、aud、issといったクレームを使った検証は可能です。

まとめ

ログインが必要なサービスで、開発時にログイン回りをどう処理すればいいのか、というのはいつも悩むポイントです。いろんなログイン方式が使えるサーバーであればID/パスワードでログインする機構を別に作ったり、本番同等の認証サーバーを立てて、テストユーザーを入れるなどもあるでしょう。ですが、外部システムへの依存があると結合テストやCIがやりにくくなったりもしますし、処理時間も伸びてしまいます。あと、せっかくMSAL.jsを使えば認証の組み込みが簡単なのに、認証回り以外にたくさんのif文が入るのもうれしくありません。

今回はテスト用にAzureADのログインをバイパスしダミーのJWTを作るという方向で実装しました。比較的影響範囲をログイン回りに閉じ込めつつ実装できたんじゃないかな、と思います。

Auth0のドキュメントに記載されているAPI操作は、curlコマンドで記載されています。

一方で、PowerShell標準の Invoke-webRequestやInvoke-RestMethod を用いて操作するといった日本語情報が少ないと思ったため、GETとPOSTリクエストの方法をまとめました。

ついでに、Auth0にいる全ユーザー数を取得する方法も共有します。

Windowsのcurl事情

CLIから通信を行える便利コマンド curl は元々UNIX系のコマンドで、もともとWindowsにはインストールされていませんでした。

こちらの記事によると、2018年のWindows 10 Ver.1803からCurl.exeがWindowsにデフォルトで使えるようになったそうです。そこからは、コマンドプロンプトなら、curl、PowerShellの場合curl.exeと打てばcurlが使えます。

ここで大事なことですが、2018年までcurlが使えなかった時代の名残なのか、 PowerShellの場合、curl と打つとWindows用のcurlであったInvoke-WebRequestが実行されてしまいます（curl.exeだとcurlが動くが、curlにはinvokeコマンドのエイリアスが貼ってある）。普段Windows環境を触らない人にとって、高度な罠ですね。

PS C:\Users\xxxx> curl

コマンド パイプライン位置 1 のコマンドレット Invoke-WebRequest
次のパラメーターに値を指定してください:
Uri:

そのため、筆者のようにPowerShellでは 一般にイメージする curl がないものだと認識し、Invoke-webRequest や Invoke-RestMethod を使う必要があると勘違いする人も少なくないと思います。今回の記事は一連のAuth0のドキュメントにあったcurlコマンドをInvoke-RestMethodに置換して実行する流れを、一晩かけて勢いでまとめた記事です。

すべてを書き終えた後、先輩社員にcurl.exeすればcurl出来るよと言われ悲しくなりましたが、2023年10月、2027年1月までサポートを受けているWindows Server 2012、2016にはcurlがないと思われるので、そういった環境を扱う方には有用だと思います。ちなみに、Windows Server 2019には curl.exe がありましたので、素直にそちらで操作すると良いでしょう。

注意ですが、この記事に記載しているcurlコマンドをコマンドプロンプト上で動かす場合は、\のエスケープと、改行を消す必要があります（記事上では読みやすさのために改行を入れています）。

結論から話すと

以下のコマンドで動きます。

1. token取得（postリクエスト）

$client_id =  "xxx"
$client_secret =  "xxx"
$api =  "https://xxx/api/v2/"

$body = @{
    client_id = "$client_id"
    client_secret = "$client_secret"
    audience = "$api"
    grant_type = "client_credentials"
}
Invoke-RestMethod -Method Post -Uri "https://xxx/oauth/token" -ContentType 'application/json' -Body ($body|ConvertTo-Json) -OutFile output.txt
cat output.txt

2. output.txtからtokenをコピーして2のコマンドを打つ
3. 全ユーザー数取得コマンド(getリクエスト)

$token = "copyAndPasteHere"
Invoke-RestMethod -Method Get -Uri "https://xxx/api/v2/users?per_page=0&include_totals=true" -Headers @{Authorization="Bearer $token"}

4. output.txt が不要になれば削除します

rm .\output.txt

操作の流れ

Auth0にいる総ユーザー数を取得を Invoke-RestMethod で記載する方法を共有します。

基本的には以下の2つのコマンドをInvoke-RestMethod で代替します。

1. APIを利用するtokenを取得する（POSTリクエスト）
2. 総ユーザー数取得APIを打つ（GETリクエスト）

1. APIを利用するtokenを取得する（POSTリクエスト）

ユーザー数取得に使う Auth0 User Management API を利用するためのtokenをまずは取得します。

User Management APIの利用権限のあるAPIのtoken取得コマンドが、API設定のTestタブに以下の画像のように書いてあるので参照します。tokenを取得するcURLコマンドと、すごく親切にバックエンドでよく用いる言語での取得方法まで記載しているので参考になります。

curl --request POST \
  --url https://$domain/oauth/token \
  --header 'content-type: application/json' \
  --data '{"client_id":"alphanumericWithCapita1Letter","client_secret":"alphanumericWithCapita1LetterChottoNaga1","audience":"https://$domain/api/v2/","grant_type":"client_credentials"}'

観察

まず元のCURLが何やってるか見ます。

• POSTリクエスト
• content typeがapplication/json形式
• dataにjson文字列でclient認証情報を渡している

dataとありますが HTTPリクエストではbody とも呼びます。ここまでで、 Invoke-RestMethodでやることは「JSONをPOSTするリクエストを作れば良い」ということが分かります。

公式ドキュメント見る

2022年11月時点ではpowershell-7.3が最新のようで、公式ドキュメントはこれです。

Invoke-RestMethod
      [-Method <WebRequestMethod>]
      [-FollowRelLink]
      [-MaximumFollowRelLink <Int32>]
      [-ResponseHeadersVariable <String>]
      [-StatusCodeVariable <String>]
      [-UseBasicParsing]
      [-Uri] <Uri>
      [-HttpVersion <Version>]
...

中々難しそうですが、コレを見ると、 Invoke-RestMethodで各オプションを付ければ良い ことが推測できます。

CURLで指定したオプションは以下のようにマッピング出来そうですね。

• –requestは-Method
  • -Method Post
• –urlは-Uri
  • -Uri https://$domain/oauth/token
• –headerはHeadersとContentTypeが両方ありますね、ContentTypeだけ指定するので-ContentTypeのみ使います（Headersにcontent-typeと入れたらエラーになってました）
  • -ContentType application/json
• –dataは-body
  • 後述しますがいい感じに書かないとNGでした

これで、bodyに当たる部分以外は良い感じにマッピング出来ました。

続いてはbodyの記載方法を見ます。

ぱっと見は理解することが難しいですよね。オブジェクトで渡せば良いのかな？ とわかります。

公式にPOSTの例があるので参考にできます。

$Cred = Get-Credential
$Url = "https://server.contoso.com:8089/services/search/jobs/export"
$Body = @{
    search = "search index=_internal | reverse | table index,host,source,sourcetype,_raw"
    output_mode = "csv"
    earliest_time = "-2d@d"
    latest_time = "-1d@d"
}
Invoke-RestMethod -Method 'Post' -Uri $url -Credential $Cred -Body $body -OutFile output.csv

どうやらシェル内でオブジェクトを作れば良さそうだとわかります。この例を参考に以下のように動かすと エラーになります。

$body = @{
    client_id = "alphanumericWithCapita1Letter"
	client_secret = "alphanumericWithCapita1LetterChottoNaga1"
	audience = "https://$domain/api/v2/"
	grant_type = "client_credentials"
}
Invoke-RestMethod -Method Post -Uri "https://$domain/oauth/token" -ContentType 'application/json' -Body $body

Invoke-RestMethod : invalid json

理由ですが、bodyにjson渡す渡す詐欺（コンテンツタイプでJSON渡すと宣言してるがJSONを渡していない状態）をしてるようです。よしなにやってくれると少し期待しましたが、ダメなようです。
（※もし、何かしらの手法があれば教えてください）

対応方法

auth0 invoke rest method post body json powershell といったキーワードで探すと、こちらの記事に記載している通り、 ConvertTo-Jsonコマンドを用いbodyのオブジェクトをJSONに変換すれば良いということがわかります（-Body $body ➔　-Body ($body|ConvertTo-Json)）。

※公式ドキュメントの関連記事の箇所にも ConvertTo-Json の記載がありますが、本文にも記載があると助かる人もいるかなと思い、公式ドキュメントにフィードバックは出しておきました。これが採用されると嬉しいなと思います。

結果として、以下のコマンドで動きます。

$body = @{
    client_id = "alphanumericWithCapita1Letter"
	client_secret = "alphanumericWithCapita1LetterChottoNaga1"
	audience = "https://$domain/api/v2/"
	grant_type = "client_credentials"
}
Invoke-RestMethod -Method Post -Uri "https://$domain/oauth/token" -ContentType 'application/json' -Body ($body|ConvertTo-Json)

しかし、少し斜め上な結果になります。

出力結果最後まで出ない問題

PowerShellの仕様か、Invoke-RestMethodの仕様なのか、出力が最後まで出てくれずトークンが分からない問題 が発生しました。

解決策として、公式の例を真似てファイルに出力して表示することにします（愚直にoutput.txtに出してcat output.txtします）。シェルに詳しい人だったら良い感じにCLIの出力出来たかもしれないですが、詳しい方は教えてください。

そのため、以下のコマンドを付けます。

... -OutFile output.txt
cat output.txt

総ユーザー数取得APIを打つ

最初に、Auth0全ユーザー数の取得コマンドを探すため、公式で用意されているAuth0 User Management APIのドキュメントを見ます。

そうすると、Users　➔　List or Search Usersの箇所のパラメータを眺めてると 小さく取得できる旨が書いて あります。APIの概要にはページング番号を指定しながらのユーザー取得しかできないかのように書いてあるが、よくよくパラメータを見ると取得できることがわかります。

API概要:1ページに取得されるユーザー数を指定してユーザーリストを取得できるんやでと記載されています。

Retrieve details of users. It is possible to:

- Specify a search criteria for users
- Sort the users to be returned
- Select the fields to be returned
- Specify the number of users to retrieve per page and the page index

パラメータ:include_totalsをオンにするとAPIのレスポンスにトータルを含められると書いています。

include_totals
Return results inside an object that contains the total result count (true) or as a direct array of results (false, default).

しかし、この説明文だと、表示するページの合計なのか、全体なのか曖昧ですよね。

また、概要にある通りユーザーのリストが取得できてしまうが、合計人数だけ知りたいのでユーザー情報をなくすオプションを探します。※全パラメータは任意。

per_pageに着目するとinclude_totalsだけ指定してper_pageを空にした場合全ユーザー情報が取得できてしまうようです。そしてユーザー取得フラグのようなものはなく、 per_pageをいじるしかなさそう なので、一旦これを0にしてAPIを実行することにします。

token取得時と同様に、まず成功するcurlコマンドを共有します。401認証失敗エラーにならないようにtokenをつけます。

curl --request GET \
  --url "https://$domain/api/v2/users?per_page=0&include_totals=true" \
  --header 'authorization: Bearer $token'

観察・マッピング

クエリパラメータはGETなのでシンプルですね。token渡したGETリクエストするだけです。公式ドキュメントのリンクはこちらです。

• GETリクエストをしている
  • --request GETが--Method Getになる
• URLにPOSTと違いクエリパラメータがある
  • --urlが-Uriになる
  • -Uri https://$domain/api/v2/users?per_page=0&include_totals=true
  • URLにパラメータを入れることをクエリパラメータと言う
• token認証情報を渡している
  • --headerが-Headersになる
  • -Headers @{Authorization="Bearer $token"}
  • cURLと違いInvoke-RestMethod特有のオブジェクト形式で書かないといけないので@{xxx}の形式となる
  • Authenticationオプションなどでも指定可能だったかもしれない（未検証）

以上からInvokeコマンドに書き換えます。

Invoke-RestMethod -Method Get -Uri "https://$domain/api/v2/users?per_page=0&include_totals=true" -Headers @{Authorization="Bearer $token"}

start  : 0
limit  : 0
length : 0
users  : {}
total  : xxx

無事totalの数字が取得できました！

さいごに

curlコマンドの代替として、PowerShell標準の Invoke-webRequestだったりInvoke-RestMethod を用いてAuth0のAPIを操作する例をまとめました。

IT初心者がIT課題をどう解決していけば良いのか何となく分かるような文章を書けたら良いなと最近考えているため、ハマった部分や調査の流れもなるべく残すように記載しました。ググっても情報が見つかりにくかったことを記事にして誰かを助ける備忘録にもなってたら良いなと思います。

この記事が良いなと思ったら感想下さると励みになります。Twitterなどでコメントいただけると幸いです。

業務システムで扱う認証にはいろいろな種類がありますが、だいたい以下のどれかに該当するケースが多いと思います。

• Webサービス・モバイルアプリ: 一般ユーザーでログイン
• デスクトップで動かすバッチコマンド: 一般ユーザーでログイン
• デスクトップやサーバーで動かすバッチコマンド: 無人運用

Webサービスのうち、SPAは前回のエントリーで説明しました。Webサービスの認証は前回説明しました。今時の動的ページはSPAが主流と考えれば旧来のOpenID Connect（コールバックをウェブサーバーで受けてトークン発行はサーバーで行う）は説明不要でしょう。モバイルアプリについては使うフレームワークによっても変わるので割愛します。

本稿では、それ以外のケースとして、バッチコマンドの認証について扱います。今度はウェブ以外の認証ということで、MSAL for Goを使って認証します。上にあげたように、一般ユーザーでログインするケースと、無人運用の2つのケースを取り上げます。

一般ユーザーの認証

一般ユーザーは、WindowsとかOffice 365とかにログインする、いわゆる普通のユーザーです。この権限でトークンをとってAPIを実行すると、そのユーザーが操作したことになります。コマンドを動かした人の名前がログが残るということです。一般ユーザーの場合は、コマンドはまず、ユーザーに「お前誰よ」と聞く必要があります。

コマンドが自前でユーザーIDとパスワードの入力欄を出して入力させ、それを認証で使うフロー（Resource Owner Password Credentials Flow）は以前はありましたが、OAuth 2.1で無くなることが確定しています。ブラウザを表示してAzureAD認証をユーザーに行ってもらい、その結果のコードを使ってトークンを取得する方法がOAuth 2.1時代に唯一現存する方法です。そのため、通信方式としては、前回のSPAモードと同じく、Authorization Code Flowとなります。この方式はSPAと同様にパブリッククライアント用のモードなのでバッチコマンドを悪意のあるユーザーに奪取されて解析されたとしても直接それがセキュリティホールにはなりません。

まずは、AzureADの管理画面でアプリケーションを登録します（前回同様）。前回同様、テナントIDとクライアントIDはメモしておきます。

その後、認証のセクションで認証方式を追加しますが、今回はモバイルアプリケーションとデスクトップアプリケーションを選択し、カスタムのコールバックのアドレスで、ローカルホストのパスを指定します。ポートも指定する必要があります。また、/callbackなどのパスは不要です（後述）。

Go版のMSALは以下のようにしてインポートします。

go get github.com/AzureAD/microsoft-authentication-library-for-go

なお、追加でいくつかimportしないとエラーが出ます。不思議な構成。

go get github.com/AzureAD/microsoft-authentication-library-for-go/apps/internal/oauth/ops/accesstokens@v0.7.0
go get github.com/AzureAD/microsoft-authentication-library-for-go/apps/errors@v0.7.0
go get github.com/AzureAD/microsoft-authentication-library-for-go/apps/public@v0.7.0

モバイルアプリとかのパブリッククライアントは.../apps/publicパッケージにあります。前回のエントリーでも紹介したパブリッククライアント用のパッケージです。これを使ったバイナリはリバースエンジニアリングされても、不正ログインされる材料は提供しません。

このライブラリを使ったコードは以下の通りで、JavaScript版とほぼ同じAPIで似たように書けます。

package main

import (
    "context"
    "log"

    "github.com/AzureAD/microsoft-authentication-library-for-go/apps/public"
)

func main() {
	pc, err := public.New("{クライアントID}", public.WithAuthority("https://login.microsoftonline.com/{テナントID}"))
	if err != nil {
		log.Fatal(err)
	}
	result, err := pc.AcquireTokenInteractive(context.Background(), []string{"User.Read"}, public.WithRedirectURI("{コールバックURL}"))
	if err != nil {
		log.Fatal(err)
	}
	log.Println(result.AccessToken)
}

これだけで実現できました。

一般ユーザー方式の蛇足な説明

Go版のコードをみると、コールバックURLをパースして、ポート番号を取り出して自分でウェブサーバーを起動し、ブラウザからのリダイレクトを受けられるようにしています。このサーバーはコールバックのパスの部分を認識してくれないため、AzureADの登録ではhttp://localhost:5173のような形式にしないと「コールバックアドレスが登録と違う」というエラーになってしまいます。また、コールバックアドレスを設定しないと、ランダムなポート番号で起動します。ただ、ポート番号が一致しないと失敗となるので、何かしらのポートを登録しないといけないはずです。

認証方式でお手軽だったSPAを選ぶとよさそうですが、これは「cross-origin requestsじゃないとダメ」というエラーが出ます。また、一般のウェブを選ぶと「client_assertion’ or ‘client_secret」が必要というエラーが出るので、今回選んだ「モバイルアプリケーションとデスクトップアプリケーション」一択です。

また、モバイルアプリケーション云々では、独自のスキーマのコールバックURLを自動で作ってくれていました。MSAL用とあるので使えそうですが、これはin app browserなど、特定のスキーマの通信を横取りできる環境ようになっています。今回は一般のブラウザを使っているのでこの方式は使えません。

無人運用の認証

バッチ処理などではログイン画面を出したりはできません。特定のユーザーのIDやパスワードを焼き込んで使い、退職にともなって停止して困った、みたいな話は昔から何度も聞きます。これは運用として間違っています。システムユーザー的なものを使って運用するのがベストです。しかし、前述のようにパスワードをツールが直接扱う認証は非推奨です。OAuth 2.1時代に使える方式としてはクライアントシークレットを使った認証方式になります。

まずはシークレットを生成します。「証明書とシークレット」を選択し、新しいクライアントシークレットを選択してシークレットを作ります。

出来上がると、「値」と「シークレットID」が表示されますが、値の方が必要なものなので、コピーしておきます。

これを組み込んだコードが以下の通りです。前回のエントリーや前述のパブリッククライアントのケースとは異なり、今回は.../confidentialなパッケージを使っています。これはコンフィデンシャルクライアントで、攻撃者がバイナリにさわれない環境を想定しています。クライアントシークレットを奪取されてしまうとログインできてしまうのでこのバッチコマンドは（広く配布しない前提の）社内専用ツールだったり、バッチサーバーでのみ運用するケースでしか使ってはいけません。

package main

import (
    "context"
    "log"

    "github.com/AzureAD/microsoft-authentication-library-for-go/apps/confidential"
)

func main() {
	s, err := confidential.NewCredFromSecret("{クライアントシークレット}")
	if err != nil {
		log.Fatal(err)
	}
	cc, err := confidential.New("{クライアントID}", s,
        confidential.WithAuthority("https://login.microsoftonline.com/{テナントID}"))
	if err != nil {
		log.Fatal(err)
	}
	result, err := cc.AcquireTokenByCredential(context.Background(), []string{"https://graph.microsoft.com/.default"})
	if err != nil {
		log.Fatal(err)
	}
	log.Println(result.AccessToken)
}

要注意ポイントはスコープの指定です。「リソースのURL」と「権限（パス形式）」を組み合わせたURL形式で指定します。SharePointだと、https://{サイト名}.sharepoint.com/{権限}です。権限部分は/.defaultか、ここに書いてあるようなSites.FullControl.Allのような文字列を使います。なぜパブリッククライアントの時と違う名前なのか・・・

認証のキャッシュ

バッチ処理を毎秒実行するとして、毎秒認証するのは無駄が多いでしょう。トークンが有効な間は同じトークンを使いまわしたいところです。MSAL for Goでは自分でキャッシュ機構を作ることが可能です。といっても、大体はファイルへの読み書きだと思うので、次のサンプルの通りに実装すればおしまいです。

https://github.com/AzureAD/microsoft-authentication-library-for-go/blob/dev/apps/tests/devapps/sample_cache_accessor.go

パブリッククライアントの場合は次のオプションをNewに追加します。

public.WithCache(&TokenCache{"ファイル名"})

コンフィデンシャルクライアントの場合は次のオプションをNewに追加します。なぜ違う名前なのか・・・

confidential.WithAccessor(cache)

まとめ

今回もバッチコマンドを想定してAzureADと認証するためのライブラリを使った認証を試してみました。

この手の検証は、アプリケーションのコード側だけではなく、接続先のAzureADの設定によっても接続が失敗する可能性があります。また、このあたりの設定はクリティカル度が高いため、アクセスできる人はなるべく少なくする運用がされることがほとんどです。特に受託開発で、お客さん側でAzureADの設定を管理している場合など、開発側では直接コンソールが触れずに、エスパーしながら試行錯誤しなければならない場面があります。お客さん側にも時間を取ってもらわないといけないし、自由な試行錯誤が難しかったりと、靴の裏から足の裏を掻くようなもどかしいことになります。
前回と今回のエントリーは、そのような場合にも対応できるように、AzureAD側の設定の依頼が投げやすいように、開発のストレスを下げたい、という思いで管理画面側の設定もなるべく具体的に書いています。

MSAL系のライブラリにはたくさんの実装がありますが、ウェブフロントエンドもGoも、APIはほぼ一緒でした。Javaとかみてみてもすぐにキャッチアップできそうです。簡単で安全な接続ができるため、接続先がAzureADであれば積極的にMSALシリーズを活用してみると良いと思いました。

AzureADを使って認証している企業は多いと思います。このAzureADを使った場合にはMSAL.jsを使えば認証は楽だぞ、というのはAzureADのサイトには書かれているのですが、OpenID Connectのプロトコルの動きの理解と、ライブラリのAPIがどう対応づいているのかがわからずにちょっと試行錯誤したので、そのメモを残しておきます。

OAuth 2.1(現在策定中)ではImplicit Code Flowが非推奨になり、Authorization Code FlowにPKCEが追加されて、コード横取り攻撃への耐性が強化されて、モバイルアプリケーションや、ウェブフロントエンドなどのパブリッククライアント（ユーザー側で動作するため攻撃者が自由にいじれる）でも安全に認証できるようになります。OAuth 2.1自体はまだ作業中ではありますが、これはOAuth 2.0から少しずつ追加されたアップデートをまとめたバージョンであり、現在でもこれらの機能は使えます。

MSAL.js 2.0というMicrosoft製のライブラリはこのPKCE対応をうたっているライブラリなので、このライブラリを使えば、コールバックハンドラーをサーバー側で用意せずとも、ウェブフロントエンドだけで認証が可能となるはずですので、実験してみました。

実現したいことは…

• MSAL.js (npmのパッケージ名は@azure/msal-browser)を組み込む
• フロントエンドだけで認証する

なお、このライブラリには、ReactとAngular向けのフレームワーク向けのラッパーライブラリが提供されていますが、動きを知るために直接このライブラリを使うものとします。

まずは実験用のサービスをAzureADに登録する

まずはAzureのActive Directoryのコンソールにアクセスしてアプリケーションを登録します。

• 名前は適当に(azuread-testでもなんでも)
• サポートされているアカウントの種類も任意
• プラットフォームの種類は シングルページアプリケーション(SPA) 、コールバックURLはhttp://localhost:5173/callbackにする（ローカルで動かす開発サーバーで受けるため）

なお、すべての項目はあとで修正できますので(アカウント種類はマニフェストエディタでJSONいじる必要があって面倒ですが)、気軽な気持ちで作成できます。また、リダイレクト情報は複数登録できます。

作成したあとにアプリケーションを選ぶと、アプリケーションの基本情報が表示されますが、次の2つのUUID型式のIDはあとで大事になります。

• アプリケーション (クライアント) ID
• ディレクトリ (テナント) ID

ウェブフロントエンドの作成

今回はVue.jsで作ってみました。認証部分はプラグイン化して使えるようにします。ReactであればContext化すればよい気がします。Vueのアプリケーションを適当に作ります。僕はVite.jsで作りましたが、vue-cliでもNuxt.jsでもなんでもOKです。

まずはMSAL.jsをインストールします。

npm install @azure/msal-browser

次に認証情報を設定するファイルを作成します。先ほど作ったアプリケーションの情報を登録します。

import type { Configuration } from "@azure/msal-browser";

export const config: Configuration = {
    auth: {
        authority: "https://login.microsoftonline.com/{テナントID}",
        clientId: "{クライアントID}",
        redirectUri: "http://localhost:5173/callback"
    },
    cache: {
        cacheLocation: "localStorage",
        storeAuthStateInCookie: false,
    }
};

次にプラグインを作ります。今回は基本的にログインしっぱなしの想定で、未ログインアクセスを許容しない前提でいます。もし、ページによっては未ログインを許可してVue Routerでアクセス制御するのであれば、ログインしているかどうかを確認するメソッド（auth.getAllAccounts()が1つもない）を追加しておけば組み込みがしやすいでしょう。

import { App } from "vue";
import { Configuration, PublicClientApplication} from "@azure/msal-browser"

let auth: PublicClientApplication;
let accessToken = "";

export async function init(config: Configuration) {
    auth = new PublicClientApplication(config);
    await auth.handleRedirectPromise();
}

export type AuthPluginType = {
    login(): Promise<string>;
    logout(): Promise<void>;
    accessToken(): string;
}

export const AuthPlugin = {
    install(app: App, config: Configuration) {
        app.config.globalProperties.$auth = {
            async login() {
                if (auth.getAllAccounts().length > 0) {
                    auth.setActiveAccount(auth.getAllAccounts()[0]);
                    const result = await auth.acquireTokenSilent({
                        scopes: ["{クライアントID}/.default"], // 11/30修正
                        redirectUri: config.auth.redirectUri
                    });
                    accessToken = result.accessToken;
                    return accessToken;
                } else {
                    await auth.acquireTokenRedirect({
                        redirectStartPage: location.href,
                        scopes: ["{クライアントID}/.default"], // 11/30修正
                        redirectUri: config.auth.redirectUri
                    });
                }
            },
            async logout() {
                await auth.logoutRedirect();
            },
            accessToken() {
                return accessToken;
            },
        };
    }
};

このlogin()メソッドが肝です。

• すでにログイン済みの場合はPublicClientApplication.getAllAccounts()がユーザー一覧を返すのでアクティブユーザーとして設定する。本当はidTokenClaims.audがクライアントIDと一致しているものを探すというのを丁寧にやった方がいいかもしれないけど、今回のケースではそもそも違うクライアントIDのユーザーアカウントがここに入ることは今のところないので雑に最初の要素をピック。
• PublicClientApplication.acquireTokenSilent()はログイン済みであればアクセストークンをAzureADに問い合わせることなく取得してVue.js内で使える形で返すが、未ログインだと例外を投げる。
• 未ログインだった場合にPublicClientApplication.acquireTokenRedirect()を使ってAzureADにリダイレクトしてログインを行う。

いろいろ試行錯誤しましたが、たぶんこれが最小ケースです。

なお、MSAL.jsにはリダイレクトモードだけでなく、SPA向けのポップアップモードがありますが、Chromeでは動かず、Edgeでしか動きませんでした。そもそも別ウィンドウでログイン画面が出るため、未ログイン時の画面のブロックとかを実装するのは手間なので、今回紹介したリダイレクトモードの方が手間が少なくて済むかと思います。あと、ChromeもEdgeも、デフォルトで別ウィンドウのポップアップはブロックされるという問題もあります。今のところ選ぶ理由が見当たらないです。

**(11/30追記)**なお、スコープは['{クライアントID}/.default']は["User.Read"]でもトークンは取得できるのですが、生成されたアクセストークンをvalidationすると必ずエラーになってしまいます。アクセストークンをサーバー側で検証することでログインが正常に行われたかどうかを判定するのがログインの肝なので、このスコープ名には注意してください。Microsoftの提供するAPIを利用する場合はその該当するAPIをスコープにすればOKです。この場合は自分での検証はできません。詳しくは以下のリンク先を参照してください。

• https://stackoverflow.com/questions/45317152/invalid-signature-while-validating-azure-ad-access-token-but-id-token-works

TypeScript用にプラグインの型定義も書いておきます。

import type { AuthPluginType } from "./authPlugin";

declare module "vue" {
  interface ComponentCustomProperties {
    $auth: AuthPluginType
  }
}

組み込み

PublicClientApplicationの初期化はVue.jsとかよりも先に行います。

import { createApp } from 'vue'
import App from './App.vue';
import { AuthPlugin, init } from './authplugin';
import { config } from './authconfig';

await init(config);

const app = createApp(App);
app.use(AuthPlugin, config);
app.mount('#app');

MSAL.jsは初期化時に、AzureADからのコールバックでフロントエンドが呼ばれた場合の、クエリー文字列にOAuthの認証コードが付与されている場合には、「コールバックが来たぞ！」と検知して、OpenID Connectの認証処理の続きを行ってくれます。そして、その後redirectStartPageで指定したURLにリダイレクトまでやってくれます。そのために、init()で待ち（正確にはauth.handleRedirectPromise()を待つ）を入れています。awaitを忘れるとエラーが出て認証に失敗します。

コンポーネントへの組み込みは以下の通りです。プラグインで作成したlogin()とlogout()を呼び出せるようにしています。あとは、アクセストークンもプラグイン経由で取得できますので、あとはこれをサーバーAPIリクエスト時にヘッダーに設定すればOKです。

<script lang="ts">
export default {
  methods: {
    logout() {
      this.$auth.logout();
    }
  },
  async created() {
    await this.$auth.login();
    console.log(this.$auth.accessToken());　// アクセストークン表示
  }
}
</script>

<template>
  <div>
    login test
  </div>
  <button v-on:click="logout">logout</button>
</template>

デバッグ

結構はまったのですが、ログインの途中でとまったときは、セッションストレージにゴミが残ります。この状態でMSAL.jsのAPIを呼んでも、処理中のものがあるというエラーになってしまうので、ブラウザを再起動するか、開発者ツールでセッションストレージを掃除します。

あとは、 auth.handleRedirectPromise() のPromiseのエラーとか返り値を見てみるのも良いです。

セキュリティ強度を変えるためのチューニング

今回は1人1台専用のマシンがある前提のコードになっているため、ブラウザ再起動でもセッションが残るようにlocalStorageに入れていますが、そうでない場合はブラウザを落としたら認証情報もリセットされるようにsessionStorageにしてあげた方が良いでしょう。上記のサンプルコードのauthConfig.tsで変更できます。

あとはこの形式だとサーバーを介さずにフロントだけで認証するため、サーバー側からアクセスの無効化などができません。フロントで作ったトークンをサーバーに送って「使っていいよ」というお墨付きを与える（あるいはユーザーごとに1セッションしか認めず、後からログインしたら先のログインは無効）みたいなロジックとかを作ればそのような問題には対処できるかもしれませんが、それであればフロントエンドだけで認証という方式ではなく、最初からアクセストークンの発行はサーバーに任せた方が良い気もします。

まとめ

PKCEの恩恵で、サーバーいらずの認証が実装できました。サーバーで認証する場合、サーバー側に設定を入れる必要があり、ダメだった場合に何度もデプロイしてテストしたり不便でしたが、とても簡単に実装できました。

サーバー側としては、JWTの検証だけは必要となりますので、そこだけ実装が必要です。MSAL.jsのリポジトリにサーバー側でのトークン検証のサンプル(Express利用)があるので、見てみると良いでしょう。

こんにちは。TIG の吉岡です。秋のブログ週間 10 本目の投稿です。

2022年の 5 月に Apple, Google, Microsoft そして FIDO Alliance が マルチデバイス対応FIDO認証資格情報 を発表してから、パスワードレス技術に対する注目が高まっています。¹ パスワードレスの概要について調査してまとめてみました。

私たちとパスワード

今日、私たちのデジタルアイデンティティはパスワードに支えられています。私たちは日々 Google で検索し、Netflix を観て、Twitter でつぶやき、Amazon で買い物をしますが、これらすべてのアカウントが、パスワードによって保護されています。

パスワードは通常 TLS によって安全にクライアントからサーバに転送され、サーバ上で難読化されて保存されるため、攻撃者が任意のパスワードを即座に奪取することは困難です。しかしながら、秘密鍵であるパスワードを他者と共有する方法は、本質的で避けることのできない問題を複数孕みます。

パスワードの抱える問題

1. ユーザがパスワードを適切に管理するのは困難である
2. サーバや通信経路からパスワードが漏洩することがある
3. パスワードにはフィッシング耐性がない

ユーザがパスワードを適切に管理するのは困難である

IPA によると、パスワードは、できるだけ長く、複雑で、使い回さないものとすべきだそうです。²それはそうなのですが、このベストプラクティスを人間が実践することは事実上不可能です。私たちは数百のアカウントを保持しています。そのアカウント全てに対して、ユニークでランダムな文字列を記憶できないでしょう。残念なことに、複数のサービスでパスワードを使い回しているユーザも多くいるようです。

サーバや通信経路からパスワードが漏洩することがある

ユーザがパスワードを適切に管理していたとしても、通信経路やサーバにセキュリティ上の不備がある場合、パスワードが漏洩し、ユーザのアカウントが危険に晒される場合があります。通常、パスワードは難読化された上でデータベースに保存されますが、平文で保存されたパスワードが漏洩した事例 も存在します。ユーザにとって、ウェブサービスが適切に管理・運営されていることを断定的に知る術はなく、パスワードの使用には本質的な危険が伴います。

パスワードにはフィッシング耐性がない

パスワードは、人間であるユーザが直接入力できる文字列であり、フィッシング耐性がありません。普段からフィッシング詐欺の被害に遭わないよう注意している人であっても、急いでいるときや慌てているときに、適切に入力先ウェブサイトの真正性を確かめるよう徹底することは、簡単なことではありません。また、ミスリード URL やホモグラフ攻撃 に常に気をつける必要があるというのは、それだけでも大きな心理的負担です。パスワードには本質的にフィッシング耐性がなく、人間の注意力に期待するのは無謀でしょう。

パスワードマネージャ

このようなパスワードの惨状に際して、パスワードマネージャを利用することが、現時点でのベストプラクティスであり、唯一のまともな解決策であると筆者は考えています。プラットフォーマーとして Apple は iCloud Keychain を、Google は Google Password Manager を提供していますし、サードパーティとしても 1Password や Bitwarden、Dashlane のような有力なプレイヤーが存在します。

ユーザは信頼できるパスワードマネージャを適切に使用することで、パスワードに潜む問題をある程度解消できます。パスワードマネージャはユニークでランダムなパスワードを作成・管理でき、また、常にオートフィル機能を使うようにすれば、フィッシング被害を受ける可能性も大きく下げることができます。

ところがパスワードマネージャも銀の弾丸ではありません。オートフィルが活用できないような場面では相変わらずフィッシングの被害を受ける可能性がありますし、サーバからパスワードが漏洩するような事態に対しても、ユーザは無防備のままです。

公開鍵暗号の活用

根本的な問題は、秘密鍵であるパスワードをクライアントとサーバが共有する、という現状のモデルにあります。トランスポート層では 10 年以上前から SSL/TLS として公開鍵暗号が大活躍しているのに、アプリケーション層で同様の技術を活用しない手はありません。公開鍵暗号を活用し、パスワードへの過度な依存を軽減するため、2012 年に Fido Alliance が設立されました。

パスワードレスと FIDO Alliance

FIDO Alliance は、パスワードに対する依存を軽減するため、PayPal や Lenovo らにより 2012 年に結成された業界団体です。現在では Amazon, Apple, Google, Microsoft などが参加する一大アライアンスに成長しています。FIDO は、TPM や生体認証機能を備えた認証器 (スマートフォンやセキュリティキー) を活用し、ユーザがパスワードを利用することなくアカウントにログインできるようにすることを目的としており、そのための標準規格をいくつか定めています。

FIDO が発表した重要な規格には、FIDO 1.0 (2014) と FIDO2 (2018) があります。

FIDO v1.0

FIDO v1.0 は FIDO UAF (Universal Authentication Framework) と FIDO U2F (Universal 2nd Factor) から成ります。FIDO UAF はスマートフォンのネイティブアプリケーション向けに、公開鍵ベースのパスワードレス認証を規定します。FIDO U2F は、パスワードに加わる第 2 認証要素として、従来通りの OTP でなく、公開鍵暗号を利用できるようにした仕様です。

この UAF と U2F ですが、仕様編纂者を見るに、UAF は PayPal が、U2F は Google が主体となって仕様策定を進めたようで、全体として足並みが揃っていない感があります。FIDO として一貫性のある仕様の実現には、FIDO2 を待つ必要がありました。

FIDO2

FIDO v1.0 にはいくつかの反省点がありました。UAF は半ばスマートフォンのネイティブアプリケーションで使うことを前提としていたため、ウェブブラウザへの応用がすすみませんでしたし、U2F はあくまで従来のパスワードを補完する技術要素にすぎず、完全なパスワードレスを実現するものではありませんでした。これらの問題を解決した最新の FIDO 仕様が、2018 年に発表された FIDO2 です。

FIDO2 は WebAuthn と CTAP から成る公開鍵ベースの認証技術仕様です。

WebAuthn

WebAuthn (Web Authentication) は、FIDO Alliance と W3C の共同作業として、2016 から作業が開始し、2019 年にウェブ標準となった仕様です。WebAuthn はウェブブラウザが認証器とコミュニケーションをとり、キーペアを作成したり、チャレンジに署名したりする方法を定めています。この仕様により、ウェブ開発者はユーザの認証器に対してキーペアの作成やチャレンジへの署名を依頼できます。2022 年 11 月現在、WebAuthn は Firefox を除くすべての主要なブラウザで完全にサポートされています。³

CTAP

CTAP (Client to Authenticator Protocol) は、OS がセキュリティキーのような外部認証器とやりとりする際の低レイヤープロトコルを規定しています。ウェブ開発者が普段意識しないような、ウェブブラウザよりも先にある世界のプロトコルです。⁴

FIDO の認証フロー

FIDO は複数の仕様を規定しており、それらの関係が複雑なのですが、公開鍵暗号を利用した認証プロトコル であるという点は、すべてに共通しています。おおまかに言って、FIDO のパスワードレス認証は次のようなフローを採用しています。

ユーザ登録

FIDO 認証のユーザ登録時にはユーザの認証器がキーペアを作成し、公開鍵をサーバに送信します。サーバは公開鍵を保存します。サーバは秘密鍵を知らないため、仮にサーバから情報が漏洩しても、第三者がユーザのアカウントを乗っ取ることはできません。

ユーザ認証 (サインイン)

ユーザ認証 (サインイン) 時にはサーバがランダムなチャレンジを生成し、クライアントに送信します。クライアントは秘密鍵でチャレンジに署名し、サーバに返却します。サーバはユーザ登録時に保存していた公開鍵で署名を検証し、有効な署名であれば、ユーザをサインインさせます。なお、このときサインイン先のドメイン名がユーザ登録したドメイン名と同一であることがクライアント側で検証されるため、FIDO 認証にはフィッシング耐性があります。

Passkeys

FIDO Alliance の設立から 10 年近くを経て、ベンダー中立な FIDO2 仕様群が策定され、多くの OS・ブラウザでサポートされるようになりましたが、この技術が一般に広く用いられるには、移行とリカバリの問題が残っていました。従来の FIDO 認証では、ユーザの秘密鍵はデバイスのセキュアストレージを出ることなく、ローカルに保存されていました。従って、ユーザが複数のデバイスを使用しているとき、デバイスごとにサービスに登録する必要がありました。また、デバイスを買い替えたとき、アカウントをシームレスに移行する機能はなく、すべてのアカウントについて、再登録が必要でした。さらに怖いことに、デバイスを紛失したり破損したりしてしまうと、アカウントに対するアクセスを完全に失ってしまう可能性がありました。

この問題を解決し、パスワードレス技術を真にユビキタスなものにするため、2022 年 5 月 5 日 (World Password Day) に、Apple, Google, Microsoft, FIDO Alliance が共同で声明を発表し、マルチデバイス対応 FIDO 認証資格情報 (通称 passkeys) への対応を推進していくことを宣言しました。Passkeys により、iCloud Keychain や Google Password Manager を通して秘密鍵をデバイス間で安全に同期でき、移行とリカバリの問題も解消されます。Passkeys は macOS 13 Ventura や iOS 16 の Safari 16 ですでにサポートされており、Google も Android と Chrome で今秋に対応 することを発表しています。

パスワードレスな未来

現状、広範に採用されているとは言い難い FIDO, WebAuthn, passkeys ですが、強力なプラットフォーマーが協力して推進していくことから、今後採用が進んでいくことが考えられます。直近では Apple, Google そして Microsoft といったプラットフォーマーによるサポートから始まっていますが、将来的には 1Password や Dashlane のようなパスワードマネージャも認証器機能を提供する予定だそうです。ユーザとサービス提供者をパスワードから解放するパスワードレス技術に今後も注目していきます。

こんにちは、TIG の吉岡と申します。Tech Blog には初投稿です。認証認可連載の 5 本目です。

業務で認証・認可に関する SaaS に触れる場面があり、そういえば OAuth, OpenID Connect の仕組みをちゃんと理解していなかったと思い、RFC を読みながら OAuth クライアントを実装してみました。N 番煎じの車輪の再発明ですが、何かの役に立てば幸いです。

※本稿において、OAuth は基本的に OAuth 2.0 を指しますが、OAuth 2.1 にて推奨されているベストプラクティスを取り入れています。
※本当は OpenID Connect にも触れたかったのですが力尽きました。また機会があれば書かせてください。

Prerequisites

この記事は、次のような方々に向けて書いています。

• OAuth を聞いたことがある
• 認証と認可の違いを認識している
• HTTP の基本的な仕組みを知っている

OAuth とは

OAuth は、サードパーティアプリケーションが HTTP サービスに対して制限付きのアクセスを取得することを可能にする認可フレームワークです。

具体的には、ある SNS アプリケーションがあり、ユーザーはこの SNS に対して、自身の Google Photos 上の画像を投稿したいとします。このとき、SNS アプリケーションに Google のユーザー名とパスワードを教えることにより、画像を取得させることもできます。しかし、この方法には、付与される権限が大きすぎる、権限を剥奪するためにはパスワードを変更するしかないなど、さまざまな問題があります。

これらの問題を解決し、サードパーティアプリケーションに適切な権限を付与するための認可フレームワークが OAuth です。

なお、2022 年現在広く使われている仕様である OAuth 2.0 は RFC 6749 により規定されています。この仕様には、後にさまざまな拡張が施されたため、それらの拡張とセキュリティに関するベストプラクティスをまとめた OAuth 2.1 が策定中です。OAuth 2.1 は OAuth 2.0 とその拡張をまとめ直した仕様として策定中であり、OAuth 2.0 を大きく変えるものではありません。

本稿では、OAuth 2.0 並びに OAuth 2.1 における代表的なフローである「認可コードグラント + PKCE」を解説します。

OAuth のロール

OAuth では、次の 4 つのロール (登場人物) が定義されています。

• リソースオーナー: リソースの所有者であるエンドユーザー
• リソースサーバー: リソースを保持しているサーバー
• クライアント: リソースオーナーが利用し、リソースに対する権限を付与されるアプリケーション
• 認可サーバー: リソースオーナーの承諾を得たうえでクライアントに対してアクセストークンを発行するサーバー

4 つのロールのうち、クライアントには注意が必要です。通常私たちがクライアントと聞くと、OS のネイティブアプリケーションやブラウザ上で動作するアプリケーションを想像してしまいますが、OAuth の言葉遣いにおいては、それらに限らず、サーバー上で動作するウェブアプリケーションもクライアントに含まれます。

また、クライアントは コンフィデンシャルクライアント と パブリッククライアント の 2 種類に分類されます。後に説明しますが、認可サーバーはクライアントを識別するために、クライアント ID とクライアントシークレットを発行します。このクライアントシークレットを安全に保持できるクライアントはコンフィデンシャルクライアント、安全に保持できないクライアントはパブリッククライアントと呼ばれます。サーバー上で動作するウェブアプリケーションはコンフィデンシャルクライアントで、OS のネイティブアプリケーションやブラウザ上で動作するアプリケーションはパブリッククライアントです。

なお、クライアントは事前に認可サーバーに登録されている必要があります。登録の方法は OAuth 仕様の範疇外ですが、多くの場合、ウェブアプリケーションとして構築されたマネジメントコンソールなどから登録できます。本稿では Google API にクライアントを登録するフローを説明します。

OAuth のグラントタイプ

OAuth では、権限付与の種類が 4 種類規定されており、これをグラントタイプと呼びます。

• 認可コードグラント + PKCE
• インプリシットグラント (非推奨)
• リソースオーナーパスワードクレデンシャルグラント (非推奨)
• クライアントクレデンシャルグラント

認可コードグラント + PKCE は、エンドユーザーの承諾を得た上でクライアントがリソースにアクセスするという、OAuth の典型的なパターンです。クライアントクレデンシャルグラントは、クライアントが直接、クライアント自身の認証情報を認可サーバーに提示して、リソースへのアクセスを取得する方法です。

OAuth 2.0 では、これらに加えてインプリシットグラント、リソースオーナーパスワードクレデンシャルグラントが規定されていますが、これらは OAuth 2.1 で削除される予定であり、もはや利用すべきではありません。

本稿では 認可コードグラント + PKCE による権限付与を説明します。認可コードグラントは、リソースオーナー・クライアント・認可サーバーの三者のやりとりによって認可を達成するため、3-legged OAuth などとも呼ばれます。

OAuth のシーケンス

認可コードグラントによる OAuth の処理シーケンスは図のとおりです。

1. ユーザーが「Google Photos から画像を取得する」ボタンを押下する
2. クライアントが 302 Found を返却し、ユーザーエージェントを認可サーバーの認可エンドポイントにリダイレクトする ¹
3. ユーザーエージェントが認可サーバーの認可エンドポイントにアクセスする
4. 認可サーバーが認証画面を表示し、ユーザーにログインを促す
5. ユーザーが認証情報を入力し、認可サーバーに認証を求める
6. 認証に成功した認可サーバーは、クライアントが要求する権限一覧をユーザーに提示し、ユーザーの承諾を求める
7. ユーザーがクライアントに対する権限の付与を承諾する
8. 権限付与の承諾を得た認可サーバーは 302 Found を返却し、ユーザーエージェントをクライアントのリダイレクト URI にリダイレクトする ¹
9. ユーザーエージェントがリダイレクト URI にアクセスする
10. クライアントは手順 9 で取得した認可コードを用いて認可サーバーにトークンリクエストを送信する
11. リクエストの有効性を検証した認可サーバーは、アクセストークンを発行し、トークンレスポンスを返却する
12. クライアントは手順 11 で取得したアクセストークンを用いてリソースサーバーにアクセスする
13. アクセストークンの有効性を検証したリソースサーバーは、リソースを返却する
14. クライアントはリソースオーナーのユーザーエージェントに対して、リソースを含む画面をレスポンスする

順に詳しく見ていきます。

Step A. 手順 1…2

手順 1 から 2 では、ユーザーをクライアントから認可サーバーに誘導します。ユーザーがアプリケーションの「Google Photos から画像を取得する」などのボタンをクリックすると、クライアントは各種パラメータを生成し、302 Found をレスポンスします。これにより、ユーザーエージェントは認可サーバーにリダイレクトされます。この認可サーバーに対するリクエストを 認可リクエスト と呼び、リクエスト先を 認可エンドポイント と呼びます。

認可リクエストは次の通りです。ここで、認可サーバーの認可エンドポイントは auth.example.com/authorize であるとします。

GET /authorize
    ?response_type=code                                     # 1
    &client_id=<client_id>                                  # 2
    &state=<state>                                          # 3
    &scope=<scope>                                          # 4
    &redirect_uri=https://client.example.com/callback       # 5
    &code_challenge=<code_challenge>                        # 6
    &code_challenge_method=<code_challenge_method> HTTP/1.1 # 7
Host: auth.example.com

1. (必須) 認可コードグラントを利用するため、response_type=code を指定します
2. (必須) クライアント登録時に認可サーバーから発行された client_id を指定します
3. (推奨) CSRF 攻撃を防ぐため、ランダムな state 値を指定します
4. (任意) リソースサーバー・認可サーバーが規定するリソースアクセスのスコープを指定します
5. (任意) クライアントが認可レスポンスを受け取るための URI を指定します
6. (推奨) ランダムに生成した code_verifier から生成されたチャレンジを指定します (PKCE)
7. (推奨) code_challenge を生成する方法を指定します (PKCE)

上の例では、認可コード横取り攻撃と呼ばれる攻撃を防ぐため、 PKCE (Proof Key for Code Exchange) という仕組みを使用しています。PKCE は、OAuth 2.0 において使用が推奨されており、OAuth 2.1 においては事実上必須となる見込みです。

ここで、PKCE を用いる場合、クライアントはまず code_verifier と呼ばれるランダムな ASCII 文字列を生成します。code_verifier を正規表現で書くと /[A-Za-z0-9-_.~]{43,128}/ です。次に、クライアントは code_challenge_method の値を選択します。code_challenge_method として有効な値は plain と S256 です。code_challenge_method の値により、code_challenge はそれぞれ次のように計算されます。

code_challenge_method == plain のとき、code_challenge と code_verifier は同一の値です。code_challenge_method == S256 のとき、code_challenge は code_verifier を SHA-256 ハッシュ関数に通した値となります。特段の技術的な制約がない限り、code_challenge_method == S256 を指定すべきです。

Step B. 手順 3…8

手順 3 から 8 では、ユーザーは認可サーバーとコミュニケーションをとります。手順 4, 5 においてユーザーは認可サーバーにログインします。この認証は、あくまで認可サーバーが認可処理を進めるために必要な認証であり、クライアントは認証情報そのものはおろか、認証情報がやりとりされていることすら知ることはありません。また、ユーザーがすでにユーザーエージェント上で対象サービスにログインしており、そのセッションが有効な場合、手順 4, 5 は省略されることが一般的です。手順 6, 7 において、ユーザーはクライアントに対する権限の付与を提示され、問題がなければそれを承諾します。権限付与の承諾を確認した認可サーバーは、手順 8 で 認可コード を発行し、これをクエリパラメータに付与して リダイレクト URI に対する 302 Found をレスポンスします。

認可レスポンスは次のとおりです。Location ヘッダにはリダイレクト URI が含まれています。ここで、クライアントのリダイレクト URI は https://client.example.com/callback であるとします。

HTTP/1.1 302 Found
Location: https://client.example.com/callback
    ?code=<authorization_code>                # 1
    &state=<state>                            # 2

1. (必須) 認可サーバーが発行した認可コード
2. (認可リクエストに state が含まれる場合必須) 認可リクエストにて送信した state 値

なお、手順 8 と手順 9 の間において、認可リクエストと認可レスポンスの state 値を比較し、これらが等しくない場合は CSRF 攻撃が行われたと判断して処理を中断する必要があります。

Step C. 手順 9…14

手順 8 により 302 Found を受け取ったユーザーエージェントは、手順 9 でリダイレクト URI に遷移します。ここにおいてクライアントは認可コードを取得し、手順 10 で トークンリクエスト を発行します。なお、トークンリクエストを受け取る認可サーバーのエンドポイントは トークンエンドポイント と呼ばれます。手順 11 において、認可コードの有効性を確認した認可サーバーは アクセストークン を発行し、トークンレスポンス としてクライアントに返却します。これ以降、クライアントはアクセストークンを用いてリソースサーバーにアクセスし、リソースへの CRUD 操作ができるようになります。

トークンリクエストは次の通りです。ここで、認可サーバーのトークンエンドポイントは auth.example.com/token であるとします。

POST /token HTTP/1.1
Host: auth.example.com
Authorization: Basic <basic_auth_token>               # 1
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code                         # 2
    &code=<code>                                      # 3
    &redirect_uri=https://client.example.com/callback # 4
    &code_verifier=<code_verifier>                    # 5

1. (必須) クライアント ID とクライアントシークレットを使用して Basic 認証します
2. (必須) grant_type=authorization_code を指定します
3. (必須) 手順 8 認可レスポンスにより取得した code を指定します
4. (必須) クライアントが認可レスポンスを受け取るための URI を指定します
5. (認可リクエストで code_challenge, code_challenge_method を指定した場合必須) クライアントが生成した code_verifier を指定します

トークンレスポンスは次の通りです。

HTTP/1.1 200 OK
Content-Type: application/json

{
  "access_token": <access_token>,  # 1
  "token_type": "bearer",          # 2
  "expires_in": 3600,              # 3
  "refresh_token": <refresh_token> # 4
}

1. 発行されたアクセストークン
2. トークンの種類
3. トークンの有効期限 (秒数)
4. リフレッシュトークン (本稿では触れない)

Google Photos API を使ってみる

ここからは、実際に Google Photos API を利用するクライアントアプリケーションを実装し、OAuth の処理フローを確認していきます。

GCP マネジメントコンソールにてクライアントを登録する

GCP に実験用のプロジェクトを作成します。

API & Services から、OAuth consent screen を設定していきます。

External を選択し、CREATE を押下します。

App information として、App name に任意の名前を設定し、User support email にはご自身の Google アカウントのメールアドレスを設定します。

Developer contact information として、ご自身の Google アカウントのメールアドレスを設定し、SAVE AND CONTINUE を押下します。

Scopes 画面において、ADD OR REMOVE SCOPES を押下します。

今回は Google Photos API を利用したいため、Manually add scopes に https://www.googleapis.com/auth/photoslibrary.readonly と入力し、ADD TO TABLE を押下します。なお、このスコープは、対象ユーザーの Google Photos リソースに対する読み取り権限を付与します。

テーブルに Google Photos API のスコープが追加されるので、チェックボックスをチェックし、UPDATE を押下します。次いで、SAVE AND CONTINUE を押下します。

Test users 画面においてテストのためのユーザーを設定します。ADD USERS を押下し、ご自身の Google アカウントのメールアドレスを入力の上、ADD を押下してください。

テーブルにご自身のメールアドレスが追加されていることを確認し、SAVE AND CONTINUE を押下します。

Summary 画面において、各種パラメータが正しいことを確認の上、BACK TO DASHBOARD を押下します。

次に OAuth client ID を作成します。Credential 画面に遷移し、CREATE CREDENTIAL, OAuth client ID と順に押下します。

実験用のサーバーは localhost:8080 に立てる予定なので、Authorization redirect URI として http://localhost:8080/callback を入力し、CREATE を押下します。

OAuth クライアントのクライアント ID とクライアントシークレットが作成されました。これらを控えておいてください。

次に、今回利用する Photos Library API を有効にしておきます。Google Photos Library API のページにアクセスし、ENABLE を押下してください。

ここまでで GCP の作業は完了です。次に、ローカル環境でアプリケーションを立て、ブラウザからアクセスします。

クライアントを実装する

ここからは、Go によりクライアントアプリケーションを実装し、実際にローカル環境で動かしていきます。なお、テストに使用したソースコードは https://github.com/tmsick/tech-blog-oauth にアップロードしました。本稿にも main.go の全量を掲載します。

なお、このアプリケーションは次の環境変数を必要とします。これらは、先ほどの手順で Google から発行されたクライアント ID とクライアントシークレットです。

• GOOGLE_CLIENT_ID
• GOOGLE_CLIENT_SECRET

掲載しているコードは簡単な検証用のコードであり、適切なエラーハンドリングを省略していますのでご承知おきください。

package main

import (
	"crypto/rand"
	"crypto/sha256"
	"encoding/base64"
	"encoding/json"
	"fmt"
	"io"
	"log"
	"math/big"
	"net/http"
	"net/url"
	"os"
	"strings"
	"text/template"

	"github.com/gorilla/sessions"
)

type TokenResponse struct {
	AccessToken string `json:"access_token"`
	ExpiresIn   int    `json:"expires_in"`
	IDToken     string `json:"id_token"`
	Scope       string `json:"scope"`
	TokenType   string `json:"token_type"`
}

type Photos struct {
	MediaItems []struct {
		ID         string `json:"id"`
		ProductURL string `json:"productUrl"`
		BaseURL    string `json:"baseUrl"`
		MimeType   string `json:"mimeType"`
		Filename   string `json:"filename"`
	} `json:"mediaItems"`
}

const (
	lenState        = 30
	lenCodeVerifier = 64
	redirectURI     = "http://localhost:8080/callback"
)

var (
	googleClientID     string
	googleClientSecret string
	store              = sessions.NewCookieStore([]byte(os.Getenv("SESSION_KEY")))
)

func init() {
	googleClientID = os.Getenv("GOOGLE_CLIENT_ID")
	googleClientSecret = os.Getenv("GOOGLE_CLIENT_SECRET")

	if googleClientID == "" {
		log.Fatal("Env var GOOGLE_CLIENT_ID is required")
	}
	if googleClientSecret == "" {
		log.Fatal("Env var GOOGLE_CLIENT_SECRET is required")
	}
}

func main() {
	http.HandleFunc("/", handleIndex)
	http.HandleFunc("/oauth", handleOAuth)
	http.HandleFunc("/callback", handleCallback)
	http.HandleFunc("/photos", handlePhotos)
	log.Print("Serving web server at localhost:8080")
	http.ListenAndServe("0.0.0.0:8080", nil)
}

func handleIndex(w http.ResponseWriter, r *http.Request) {
	tpl, _ := template.ParseFiles("templates/index.html")
	tpl.Execute(w, nil)
}

func handleOAuth(w http.ResponseWriter, r *http.Request) {
	// Save `state` and `code_verifier` to session
	session, _ := store.Get(r, "session")
	// Generate a random state
	state, _ := randomString(lenState)
	session.Values["state"] = state
	// Generate code_verifier
	codeVerifier, _ := randomString(lenCodeVerifier)
	session.Values["code_verifier"] = codeVerifier
	session.Save(r, w)

	// Generate code_challenge
	b := sha256.Sum256([]byte(codeVerifier))
	codeChallenge := base64.URLEncoding.WithPadding(base64.NoPadding).EncodeToString(b[:])

	// Redirect the user agent == Make a authorization request
	u, _ := url.Parse("https://accounts.google.com/o/oauth2/v2/auth")
	q := u.Query()
	q.Add("response_type", "code")                                           // Indicate authorization code grant
	q.Add("client_id", googleClientID)                                       // The client ID issued by Google
	q.Add("state", state)                                                    // The random state
	q.Add("scope", "https://www.googleapis.com/auth/photoslibrary.readonly") // The scope we need
	q.Add("redirect_uri", redirectURI)                                       // The redirect URI
	q.Add("code_challenge", codeChallenge)                                   // Code challenge
	q.Add("code_challenge_method", "S256")                                   // Code challenge method
	u.RawQuery = q.Encode()
	http.Redirect(w, r, u.String(), http.StatusFound)
}

func handleCallback(w http.ResponseWriter, r *http.Request) {
	// Confirm `state` matches
	session, _ := store.Get(r, "session")
	if r.URL.Query().Get("state") != session.Values["state"] {
		w.WriteHeader(http.StatusInternalServerError)
		fmt.Fprintln(w, "Invalid state")
		return
	}
	// Get `code_verifier`
	codeVerifier := session.Values["code_verifier"].(string)
	// Clear session
	session.Values["state"] = ""
	session.Values["code_verifier"] = ""
	session.Save(r, w)

	// Make a token request
	code := r.URL.Query().Get("code")
	q := url.Values{}
	q.Add("grant_type", "authorization_code") // Indicate token request
	q.Add("code", code)                       // The authorization code
	q.Add("redirect_uri", redirectURI)        // The redirect URI
	q.Add("code_verifier", codeVerifier)      // Code verifier
	req, _ := http.NewRequest(http.MethodPost, "https://oauth2.googleapis.com/token", strings.NewReader(q.Encode()))
	req.SetBasicAuth(googleClientID, googleClientSecret)
	req.Header.Add("Content-Type", "application/x-www-form-urlencoded")
	resp, _ := http.DefaultClient.Do(req)
	defer resp.Body.Close()

	// Capture the access token we've received
	body, _ := io.ReadAll(resp.Body)
	var token TokenResponse
	json.Unmarshal(body, &token)
	session.Values["access_token"] = token.AccessToken
	session.Save(r, w)

	// Redirect the user agent to the photos page
	http.Redirect(w, r, "http://localhost:8080/photos", http.StatusFound)
}

func handlePhotos(w http.ResponseWriter, r *http.Request) {
	// Fetch photos from Google Photos Library API using the access_token
	session, _ := store.Get(r, "session")
	accessToken := session.Values["access_token"].(string)
	req, _ := http.NewRequest(http.MethodGet, "https://photoslibrary.googleapis.com/v1/mediaItems", nil)
	req.Header.Add("Authorization", "Bearer "+accessToken)
	resp, _ := http.DefaultClient.Do(req)
	defer resp.Body.Close()
	body, _ := io.ReadAll(resp.Body)
	var photos Photos
	json.Unmarshal(body, &photos)

	// Render photos
	tpl, _ := template.ParseFiles("templates/photos.html")
	tpl.Execute(w, photos)
}

// randomString generates a secure random string of length `length`.
// It returns an error when `length` is negative or failed to use the platform's
// secure pseudorandom number generator.
func randomString(length int) (string, error) {
	if length < 0 {
		return "", fmt.Errorf("cannot generate random string of negative length %d", length)
	}
	var s strings.Builder
	for s.Len() < length {
		r, err := rand.Int(rand.Reader, big.NewInt(1<<60))
		if err != nil {
			return "", err
		}
		// 1<<60 == 2**60 equals to 1,000,000,000,000,000 in hex.
		s.WriteString(fmt.Sprintf("%015x", r))
	}
	return s.String()[:length], nil
}

アプリケーションのエンドポイントは次の 4 つです。

以下、ハンドラごとに処理を説明していきます。

1. handleIndex()
2. handleOAuth()
3. handleCallback()
4. handlePhotos()

1. handleIndex()

handleIndex() は、静的な HTML をレスポンスしているだけです。

2. handleOAuth()

78…86 行目において、ランダムな state と codeVerifier を生成し、ブラウザのセッションに保存しています。

88…90 行目において、codeVerifier から codeChallenge を生成しています。

92…103 行目において、認可リクエストの URL を生成し、ブラウザをリダイレクトしています。

3. handleCallback()

107…113 行目において、ブラウザが保持している state と code_verifier を取得し、セッションをクリアしています。

115…120 行目において、ブラウザが保持していた session と認可サーバからレスポンスされた state が等しいことを確認しています。これにより、CSRF 攻撃を防いでいます。

122…133 行目において、トークンリクエストを生成し、リクエストをおこなっています。

135…140 行目において、トークンレスポンスからアクセストークンを取得し、ブラウザのセッションに保存しています。

142…143 行目において、ブラウザを /photos にリダイレクトしています。

4. handlePhotos()

147…156 行目において、セッションに保存されたアクセストークンを用いて Google Photos API にアクセスし、画像情報を取得しています。

158…160 行目において、画像情報 (URL) を含むレスポンスを返却しています。

おわりに

OAuth, OpenID 周りには、なんとなく苦手意識があったのですが、今回仕様に基づいてスクラッチで実装することで、技術の基盤とセキュリティ上の考慮事項などを知ることができました。

IDaaS の採用が当然となった現在において、認証・認可周りの知識は、ウェブ技術者の基礎教養といえると思います。今後も引き続き認証・認可周りの情報をウォッチしていきます。

こんにちは。フューチャーの棚井龍之介と申します。認証認可連載の 4 本目を担当しました。

認証認可周りは最近触りたてでして、普段の開発業務では、Go・React・AWS を利用しています。

先日、React ベースのモバイル向け Web アプリに Auth0 の認証を実装したところ、Silent Authentication（サイレント認証）のタイミングでブラウザからトークンが消失し、ログイン状態が維持できない現象に遭遇しました。

調べたところ、Safari に搭載されているトラッキング防止機能の ITP（Intelligent Tracking Prevention / インテリジェント・トラッキング・プリベンション）が原因だと判明しました。

調べる過程で、Cookie の基本的な機能からアドテク周りの技術要素、最近のプライバシー保護トレンドについて触れる機会を得ましたので、技術ブログとして整理しました。

本記事では、以下の内容を扱います。

• Cookie（1st Party、3rd Party）
• ITP（Intelligent Tracking Prevention）
• ITP による、Auth0 の PKCE フローへの影響
  • 対応方法

前半は Cookie とプライバシー保護の話で、後半が Auth0 と ITP の話です。

Cookie とは

Cookie とは、Web サイトに訪れたユーザの情報を、一時的に保存する機能のことです。
この「一時保存する機能」により、ユーザのログイン状態を維持することや、Web ページに再訪したときに「この人は、以前にウチのサイトに来た〇〇さんだ！」と判定できます。

「以前に来た〇〇さん」と技術的に判定できると、次は「きっと〇〇さんならば…」という「Cookie により収集された個人属性の、Web 広告利用」へと直結させる動きが当然出てきます。

最近だとプライバシー保護の観点から、こういった Web 広告の規制が強化されるトレンドにあります。例えば、Web サイトのトップページに訪問した際に「Cookie の有効化に同意してください。Yes or No」がポップアップで表示されて、オプトインでの意思表示が求められるのは、このトレンドに乗ったものだと思います。

Cookie の分類

続いて、Cookie の分類を見ていきます。

Cookie の発行元が、訪問しているサイト（ドメイン）と同じか別かにより、1st Party Cookie と 3rd Party Cookie と呼び方が変わります。

主に、外部のサービスを利用して「ユーザ行動に合わせた Web 広告を表示したい（ターゲティング広告を実施したい）」や「ログイン状態管理などの特定の機能を外部に任せたい」ケースで 3rd Party Cookie が利用されることが多いと思います。

ITP（Intelligent Tracking Prevention）とは

ひとこと言うと、ITP は「3rd Party Cookie の利用を禁止する技術」です。

先ほど、3rd Party Cookie により実現できることの 1 つに「ターゲティング広告（ユーザの行動履歴を元にした、Web 広告最適化）」があると述べました。ターゲティング広告により、各ユーザごとに個別最適化された（高いクリック率を獲得できる見込みの）Web 広告が表示できます。これにより、Web 広告のクリック率向上 → 購入率の向上が見込まれます。アドテク技術の進歩により、この Web 広告の精度が高まるほど、広告掲載ページ・広告を載せたい企業・その仕組みを提供する企業などの「Web マーケティング」界隈にとっては嬉しい世界になります。

その一方で、プライバシー保護の観点から、以下のような考え方が広まりつつあります。

（1）Web 広告の精度が高まる
↓
（2） ユーザの趣味嗜好を高精度で特定できる
↓
（3） 高精度な趣味嗜好の情報って、それはもはや個人情報では？
↓
（4） 個人情報を無断でクロスドメインに共有するは、プライバシー保護観点から NG では？
（例えば、あるユーザ α の行動履歴を取得した A 社が、その情報を Web 広告機能を提供する B 社に「α の同意がない状況で」共有するケース）

このような考え方はメガテック企業でも意識され、Safari や Chrome などのブラウザによる規制も進んでいます。

例えば、Apple では 2017 年から Safari での 3rd Party Cookie の利用制限を段階的に導入しており、iOS14 ではついに Safari だけでなく Chrome・Firefox 含めて 3rd Party Cookie の利用が全面禁止になりました。
Google においても、Chrome での 3rd Party Cookie の利用を「2024 年後半に向けて段階的に廃止する可能性がある」と発表し、その代替技術として「プライバシー・サンドボックス」の開発・ユーザテストを進めています。ただ、Google は当初は 2022 年 1 月に規制を開始すると発表していましたが、その後に 2023 年後半に開始予定と延期し、さらに 2024 年後半と再延期しています。

Safari での ITP 規制状況を見ると、ユーザー情報のクロスサイトトラッキングを規制しようとする Apple と、規制の穴を探すアドテク企業の戦いが垣間見られます。

(*1)より詳細な規制内容はこちらを参照お願いします。

3rd Party Cookie は何もアドテク領域に閉じた技術ではなく、それ以外の分野でも利用されています。
次は、ITP により Auth0 のトークンがうまく動かなくなってしまう話に移ります。

Auth0 のトークン取得フローと ITP ブロックへの対応

Auth0 の React 用 SDK（auth0-react）を利用する場合、PKCE（Proof Key for Code Exchange）の認証認可フローに従います。フローの詳細はこちらのサイトに記載があります。

Auth0 の JavaScript SDK ではログイン成功後、トークンを取得して、ブラウザのインメモリにキャッシュされます（上図での （9） で取得した Access Token をインメモリに保存する）。インメモリに保存すると、ページ遷移や画面リロードの度にトークンの再取得が必要で色々と面倒になりそうですが、この辺のトークンリフレッシュを Auth0 側では「Silent Authentication（サイレント認証）」により解決しています。サイレント認証により、ログイン状態を維持しながら、トークンをインメモリでセキュアに保持できます。

3rd Party Cookie が ITP で強制消去される

Auth0 x React でのログイン状態の管理が
（1）ID/Pass を入力してログインし、トークンを取得
（2）サイレント認証でトークンのリフレッシュ、ログイン状態を維持
（3）トークンの破棄、ログアウト
の 3 つで完結するならばこれで話は終わりですが、昨今の ITP（3rd Party Cookie の禁止）により、（2） のサイレント認証に失敗するケースが出てきました。

例えば、会社 Z が Auth0 でログイン機能を実装した Web サービスを運営しているとします。サービスの運営会社 Z と Auth0 では「異なるドメインの会社」になるため、Auth0 の発行したトークンが、Z 社の Web ページ上では 3rd Party Cookie と判定されて、ブラウザにより Cookie が強制消去されるケースが有り得る、ということです。サイレント認証に失敗すると「ログイン状態を維持できない（ページ遷移・リロードの度にログイン処理を求めることになる）」ため、ユーザ体験を大きく損なってしまいます。

ITP により 3rd Party Cookie が消去されたとき、Auth0 のコンソール画面、Safari の Web Inspector それぞれで以下の挙動が得られます。

ITP への対応方法

サイレント認証が ITP により失敗する問題には、Auth0 公式が 2 つの対応方法を提示しています。

（1）リフレッシュトークンローテーションを設定する
（2）カスタムドメインを設定する。

この 2 つを設定すれば、ITP による 3rd Party Cookie 消失問題には対応できます。

また、ブラウザの設定変更で「ITP をオフにする」ことも可能なので、問題切り分け手法の 1 つとして覚えておくと、後々に役立つかも知れません。

以下は iPhone のブラウザ設定画面です。
スクショは ITP がオンの状態で撮影したものなので、Safari は「『サイト越えトラッキングを防ぐ』をオフ」にすることで、Chrome は「『Web サイト超えトラッキングを許可』をオン」にすることで、ITP を無効化できます。

以下はリフレッシュトークン・カスタムドメインのどちらも設定せずに、エミュレーターの Safari 設定で ITP をオフにした場合の挙動です。Auth0 のコンソール画面、Web Inspector のログから、/authorizeと/oauth/tokenが Call されて、PKCE フローが正常終了してサイレント認証に成功していることが分かります。

おわりに

モバイル向けの Web ページを作成してリリースし、リリース後の動作チェックで「あれ、iOS だとログイン状態が維持できてない！？」と気づきました。OAuth2.0 の仕様や PKCE の確認、インスペクタのログと認証フローと付き合わせながら、処理に失敗している場所の特定にまで至れました。（1）「ITP」について知見がなかったこと、（2） 事前チェックが Android と Chrome シミュレーターだけで、iOS は工数削減のため未実施だったことが根原因なのですが、スマホと PC・iOS と Android で色々細かいところが違うのなー（なので、モバイル実機テストは Android と iOS は両方やろう）と再認識する機会になりました。

参考

• Webkit
• Troubleshoot Renew Tokens When Using Safari
• Auth0 の Silent Authentication (サイレント認証)と Refresh Token Rotation (リフレッシュトークンローテーション)を完全に理解した (い)

前回はAWS API Gatewayを利用して、OIDC/OAuth2.0におけるResource ServerをCustom Authorizerで保護する記事を書いてました。

https://future-architect.github.io/articles/20210610a/

今回はAPI Gatewayのミドルウェア製品となるKongを使ってResource Serverを構築する方法について話します。

Kong Gateway

KongはOSSから始まったAPIサーバのトラフィックを管理するためのミドルウェアです。

nginxベースにLuaJITエンジンを使ってLuaスクリプトが組み込めるWebプラットフォームのOpenRestyを採用し、Luaで書かれた様々なPlug-inをデフォルトで揃え、それを組み立てることでAPIGatewayの機能を実装しています。また、Luaスクリプトで新しいカスタムPlug-inを作りそれを組み込むことも可能です。

Enterprise版が登場してからはAPIGateway以外にも様々さサービスがありますが、今回はKong Gatewayにのみ注目して行きたいです。

Kongの構造

構築の話になる前にかんたんにKongの構造を触れていきます。上の図のようにKongは基本的にConsumer/Route/Service/LoadBalancer(Upstream)の4つのレイヤリングが存在します。Kongで使う様々なPlug-inはこの4つのレイヤーのどこか、もしくはGlobalに組み込むこともできます。

• Consumer: Kongを実際利用するAPIClient(もしくはユーザ)を表すエンティティ
• Route: Requestのルールを定義するエンティティ
• Service: KongがProxyするBackendServiceを表すエンティティ
• Upstream: Backendの負荷分散やHealthCheckなどに使う仮想ホストのエンティティ

Actors

構築にあたり、まずはOIDCの役者を揃えましょう。Front/Backで分離された認証認可設計のためには、少なくとも下記3つのActorが必要になります。

Keycloak as OpenID Provider (Authorization Server)

https://www.keycloak.org/getting-started/getting-started-docker

中心となる認可サーバはOSSのKeycloakを使いましょう。ID管理、トークンや証明書の発行&管理、認証画面提供などの役割があります。
今回は上記リンク通り、Dockerを利用して構築します。Client設定は下記のVueの設定に従いましょう。
Keycloak構築はチュートリアル通りで問題ないので、詳細な実装方法は省略します。

Vue as Relying Party (Client)

https://www.keycloak.org/securing-apps/vue

FrontendとなるClientはVueを使います。認証後トークンの保持&リフレッシュ、APIサーバへリクエストを送ったりします。
今回はVueを使いますが、keycloak-jsさえ組み込めば、どのFrameworkでもかんたんにRelyingPartyを作ることができます。
Keycloak同様リンク通り実装すれば問題ないので、詳細は省略します。

Kong as Resource Server (API Server, Backend Service)

https://mockbin.org/

今回の保護対象となるResourceServerは、Gatewayとして前段に位置するKongと本丸となるBackend Service (API Server)に構成されます。Backend ServiceとしてはKongのチュートリアルで使われるMockbinをそのまま使います。

Kongの構築

https://docs.konghq.com/gateway/latest/install/

まずはKongをインストールします。Dockerなど便利なオプションもあるので好きな方法でインストールしましょう。
Kongは設定の保存先としてDBを使うのでPostgreSQLもインストールが必要です。

Kongはデフォルトで…

• Port 8001：あらゆるエンティティ設定をするのAdminAPI
• Port 8000：実際トラフィックをさばくProxy

に分かれています。

Service & Routing

https://docs.konghq.com/gateway/latest/get-started/services-and-routes/

次にKongとBackendServiceとなるMockbinをつないで、KongのURLにアクセスするとMockbinのレスポンスが出るようにします。

curl -i -s -X POST http://localhost:8001/services \
  --data name=example_service \
  --data url='http://mockbin.org'
curl -i -X POST http://localhost:8001/services/example_service/routes \
  --data 'paths[]=/mock' \
  --data name=example_route

上記のように設定することでKongの/mockへのアクセスが、Mockbinの/にProxyされるようになります。

curl -X GET http://localhost:8000/mock/requests

そうすると上のようなCurlでMockbinのAPIパスである/requestsのレスポンスが取得できます。

APIを保護する

ここまで下準備が整ったところで、本題である認証機能実装に入ります。
ClientからのリクエストはBearerTokenとしてKeycloakが発行したJWTを乗せないと拒否するようにしたいので、トークンを検証するためにKong公式のJWTプラグインを使います。

curl -X POST http://localhost:8001/plugins -d "name=jwt"
curl -i http://localhost:8000/mock/requests # 401 Unauthorized

今回はJWTプラグインをGlobalに設定しますが、特定のServiceやRouteに限定して設定もできます。

Consumer

次はConsumerの設定です。ConsumerはAPI Clientを表すエンティティですが、今回の場合は特定認可サーバ(Keycloak)に認証済みのユーザ全員を表すために予め設定するものになります。

curl -X POST http://localhost:8001/consumers -d "username=authorized_user"

JWT Credential

最後にConsumerにJWTを検証するための公開鍵を設定することで、「この検証されたトークンのBearerはこのConsumerで間違いない」ということを認証させるための設定をします。

curl -X POST http://localhost:8001/consumers/authorized_user/jwt \
-H 'Content-Type: application/json' \
-d '{"key": "http://localhost:8080/realms/{REALM_NAME}",
     "algorithm": "RS256",
     "rsa_public_key": "-----BEGIN PUBLIC KEY-----\nMIIBI...QIDAQAB\n-----END PUBLIC KEY-----"}'

key

JWTのペイロードissと同じ値を設定します。
このAPIにアクセスできるユーザ(authorized_user)は、みんな同じ認可サーバ(Issuer)から発行されたトークンを持ってる(Bearer)ことを意味します。

JWTプラグインのデフォルト設定でconfig.key_claim_name=issとなるので、別のClaimの値にしたい場合(例えばaudかazpなど)はAdminAPIの/plugins/{jwt plug-in ID}をPATCHなどして変更も可能です。

algorithm

Keycloakでデフォルトで発行するAccessToken(JWT)のアルゴリズムであるRS256を指定します。
注意するところは、もしこの設定のリクエストで下記のrsa_public_keyのPEM形式が正しくない場合でも、このフィールドのエラーメッセージが出ます。

rsa_public_key

Keycloakは同じRealmのユーザには同じ公開鍵でJWTを署名しているので、AdminConsoleのRealm Settings > KeysからRS256の公開鍵をPEM形式でセットします。
一般的にRS256のJWT検証に使われるJWKs Endpointの証明書(x5c)と違い、公開鍵であることに注意しましょう。

実際リクエストを送ってみる

普通アプリを作るならばここでClientであるVue上でKeycloakから取得したAccessToken(JWT)をAuthorizationヘッダーに載せ、KongのAPIにアクセスするコードを書くことになります。
しかし、ここではKongの機能を確認するだけでいいので、Vueが保持するKeycloakのインスタンスをダンプさせAccessTokenを取得し、curlを使います。

curl http://localhost:8000/mock/requests -H "Authorization: Bearer eyJhbGciOiJS..." | jq .
{
    ...
    "headers": {
        ...
        "authorization": "Bearer eyJhbGciOiJS...",
        "x-consumer-username": "authorized_user",
        "x-credential-identifier": "http://localhost:8080/realms/{REALM_NAME}",
        ...
    },
    ...
}

そうするとMockbinが受け取ったHeaderを上記のようなレスポンスとして返してくれます。

さいごに

といった感じで簡単に触ってみましたが、いかがだったでしょうか。

今回は割愛しましたが、expClaimで有効期限のチェックもできますし、設定のconfig.key_claim_nameとプラグインを適用するRoute/Serviceを調整する機能を組み合わせることで認可機能の実装もできます。

個人的にはどのアカウントからのリクエストかわかるように、ペイロードのsubなど一部のClaimを後ろにヘッダーとして流せる機能があったら良かったなとも思いましたが、例えばこういったカスタムプラグインを組み合わせることでなんとかなりそうです。

TIG真野です。認証認可連載の2本目です。

認証認可がテーマの中で、アクセス制御と聞くとちょっと外れているかもと思いましたが、Casbinについて紹介します。

トップページにも An authorization library that supports access control models like ACL... とあり、アクセス制御を支援する認可ライブラリだよって書いているので、OKと判断しました。

Casbinについて

ACL、RBAC、ABACなどの様々なモデルでアクセス制御を行えるライブラリです。

私が最初に存在を知ったのは、avelino/awesome-go に載っていたことからだったので、てっきりGo言語のみのライブラリかと思っていました。

実際はドキュメントを見ると、複数の言語をサポートしています。Go以外にも、Java, Node.js, PHP, Python, .NET, C#, C++, Rust, Delphi, Lua, Dart, Elixirに対応しているとのこと（言語によっては一部の機能が使えないなどあるようです）。

ドキュメントに書いてることがシンプルだったのでそのまま転載、抜粋します。

Casbinが行うこと：

1. {subject, object, action} の形式や独自定義のカスタマイズされた形式のポリシーを適用します
2. アクセス制御モデルとそのポリシーの保存をハンドリングします
3. ロール・ユーザー間のマッピングとロール・ロール間のマッピング（RBACのロール階層管理）
4. root や administrator のようなスーパーユーザのサポート
5. ルールのマッチングをサポートする複数の組み込み演算子もサポートします。 例えば、 keyMatch はリソース キー /foo/bar をパターン /foo* のマッピング

Casbinが行わないこと：

1. 認証 (ログイン時の ユーザー名 と パスワード の検証)
2. ユーザーまたはロールのリスト管理。 プロジェクトがこれらのエンティティを管理する方が利便性が高いと考えています。 Casbinはパスワードを保管しない

仕組みとしては、 PERM メタモデル (Policy, Effect, Request, Matchers) にもとづいて動作するとのこと。

ACL、RBAC、ABACについて

それぞれ用語だけ簡単に触れます。

• ACL(Access Controll List)
  • アクセス制御
• RBAC(Role Based Access Control)
  • ロールベースアクセス制御
• ABAC(Attribute Based Access Control)
  • 属性ベースアクセス制御

アクセス制御について詳しい解説は、次のようなサイトを見ると良いと思います。

• https://kenfdev.hateblo.jp/entry/2020/01/13/115032
• https://ja.wikipedia.org/wiki/%E3%82%A2%E3%82%AF%E3%82%BB%E3%82%B9%E5%88%B6%E5%BE%A1%E3%83%AA%E3%82%B9%E3%83%88
• https://www.cloudflare.com/ja-jp/learning/access-management/role-based-access-control-rbac/
• https://www.okta.com/jp/identity-101/role-based-access-control-vs-attribute-based-access-control/

PERM メタモデル について

Casbin以外で聞いたことが無いですが（一般用語でしたらすいません）、Policy, Effect, Request, Matchersの略です。

ファイルシステムのACLのイメージ図です。ポリシー定義がそのファイルの権限を誰が持っているかのリストです。モデル定義はそれをもとにどのように動作させるかを示しています。

図だと、以下を示しています。

• aliceはdata1を読み取りOK
• bobはdata2を書き込みOK

sub, obj, actは だれが、何を、どうする に置き換えるとイメージしやすいと思います。

触ってみる（Go）

GoでどのようにCasbinを動かすのか、触ってみます。

最初にPolicyを定義します。実用的にはPostgreSQL/MySQLといったDBやAmazon S3などに配備すると思います。そういったAdaptorも用意されています。今回は簡易的にCSVファイルを用います。

例としてRBACをイメージしています。

p, admin, file1, read
p, admin, file2, read
p, admin, file3, read
p, Aさん, file4, read
g, Bさん, file5, read
g, Aさん, admin

見たまんまですが、adminロールを持っている人はfile1~file3に対して権限があり、Aさんのみadminです。
また、Aさんはfile4, Bさんはfile5に権限を個別に持っています。

Goのコードとしては、モデルのロード、ポリシーのロードを行い生成する casbin.NewEnforcer() がメインどころです。このインスタンスを生成できるとあとは Enforce() で判定可能です。

package main

import (
	"fmt"
	"log"

	"github.com/casbin/casbin/v2"
	"github.com/casbin/casbin/v2/model"
	fileadapter "github.com/casbin/casbin/v2/persist/file-adapter"
)

func main() {

	modelParam, err := model.NewModelFromString(`
[request_definition]
r = sub, obj, act

[policy_definition]
p = sub, obj, act

[role_definition]
g = _ , _

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = g(r.sub, p.sub) && r.obj == p.obj && r.act == p.act
`)
	if err != nil {
		log.Fatalf("NewModelFromString: %s", err)
	}

	enforcer, err := casbin.NewEnforcer(modelParam, fileadapter.NewAdapter("policy.csv"))
	if err != nil {
		log.Fatalf("NewEnforcer: %s", err)
	}

	in := [][]any{
		{"Aさん", "file1", "read"},
		{"Aさん", "file1", "write"},
		{"Aさん", "file4", "read"},
		{"Bさん", "file1", "read"},
	}

	for _, v := range in {
		ok, err := enforcer.Enforce(v...)
		if err != nil {
			log.Fatalf("enforce: %s", err)
		}
		fmt.Printf("%v: %v\n", v, ok)
	}

}

これを動かすと、次のように想定通りの結果を得られます。

[Aさん file1 read]: true
[Aさん file1 write]: false
[Aさん file4 read]: true
[Bさん file1 read]: false

CasbinのAPIの使い方で言えば、判定するための実装そのものより、モデルのmatcherの書き方や、これらの定義をどのようにロードさせたり、変更があった場合に追随させるかといったところの方が難しいと思います。

matcherの文法:

• https://casbin.io/ja/docs/function にかかれている通り、組み込み関数が使えます。
  • ワイルドカード指定などもこれで対応できます

adaptor:

• https://casbin.io/docs/adapters に記載されている通り、複数のデータソースに対応しています。地味にEntやsqlx といったO/Rマッパーも対応していて細かいです
  • AutoSave ですが、enforcerは UpdatePolicy() で動的に定義を変更できるため、それを自動で保存する機能です
  • 例えば、何か新しいファイルやレコードが追加された時に権限を更新→自動で永続化先まで反映してくれるといった具合です

HTTPサーバの利用できるAPIをアクセス制御する

さきほどの例だとあまりイメージが付きにくいと思うので、Web APIの URL＋Method でアクセス制限する例を実装していみます。

ここでは説明のためスクラッチで書いていますが、Echo, Gin、Chiなどすでにミドルウェアで準備されています。

• https://casbin.io/ja/docs/middlewares

今回は go-chi を用いて実装します。それっぽい例を探すのが大変だっため、_examples/rest を流用しました。オリジナルのコードはそちらを参照ください。

まずはモデル定義です。

[request_definition]
r = sub, obj, act

[policy_definition]
p = sub, obj, act

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = r.sub == p.sub && keyMatch(r.obj, p.obj) && (r.act == p.act || p.act == "*")

最後のmachersだけ、条件が増えています。
keyMatch はワイルドカードを許容する関数です。例えば、 /articles/* で /articles/1234 とか、 /articles/1234/comments/5678 などを許容したいので利用しています。詳細はこちらを参照ください。
今回はワイルドカードで許容できるようにしたいので、 act 側はORで繋いでいます。 keyMatch だと GET, POST, DELETE などを * で許容できなかったのでこの書き方をしています。

ポリシーは今回もCSVファイルで定義します。

p, guest, /, *
p, guest, /ping, *
p, member, /, GET
p, member, /ping, GET
p, member, /articles, GET
p, member, /articles/*, GET
p, owner, /, GET
p, owner, /ping, GET
p, owner, /articles, *
p, owner, /articles/*, *
p, admin, /*, *

全てロールで、guest < member < owner < admin の順番で権限が強くなるイメージです。

次に、Casbinの判定をchiのミドルウェアに設定する実装イメージを書いてみました。

func main() {
	flag.Parse()
	r := chi.NewRouter()
	r.Use(middleware.RequestID)
	// 中略

	// Casbinのモデル、ポリシーをロード
	casbinModel, err := model.NewModelFromFile("model.conf")
	if err != nil {
		log.Fatalf("NewModelFromFile: %s", err)
	}
	enforcer, err := casbin.NewEnforcer(casbinModel, fileadapter.NewAdapter("policy.csv"))
	if err != nil {
		log.Fatalf("NewEnforcer: %s", err)
	}

	// ミドルウェアに設定
	r.Use(CasbinAuthorizer(enforcer))

続いてミドルウェア本体です。かなり端折って書いています。コードコメントにも書いていますが、本来はログイン後にセッションか何かにユーザーIDを載せ、紐づくユーザーロールをDBから取得するようなイメージでいます（あるいはJSTトークンにロールを載せてもらうかなど）。取得したロールも、本来は http.Requestの context.Context に載せて引き回した方が自然かもしれませんが、簡易的にリクエストヘッダーから取っています。

main関数側で設定した casbin.Enforcer で、リクエストを検証して、OKであれば後続へ。NGであれば403を返します。

func CasbinAuthorizer(e *casbin.Enforcer) func(next http.Handler) http.Handler {
	return func(next http.Handler) http.Handler {
		fn := func(w http.ResponseWriter, r *http.Request) {

			// 何かしらミドルウェアの前処理（セッションやJWTトークンから取得）でロールがリクエストヘッダーに入っているものとする
			role := r.Header.Get("user_role")
			if role == "" {
				role = "guest"
			}

			// casbinでリクエストを検証（ロール、URL、メソッド）
			res, err := e.Enforce(role, r.URL.Path, r.Method)
			if err != nil {
				http.Error(w, err.Error(), http.StatusInternalServerError)
				return
			}
			if res {
				next.ServeHTTP(w, r)
			} else {
				http.Error(w, http.StatusText(http.StatusForbidden), http.StatusForbidden)
				return
			}
		}

		return http.HandlerFunc(fn)
	}
}

実際にcurlで試してみます。ロールをリクエストヘッダで切り替えていますが、本来はこれだと意味がないので、ログイン処理などを追加して、サーバ側でロールを判定するように改修し、クライアントがロールを指定できなくする必要があります。

# guest ロール
$ curl  http://localhost:3333/ping
pong

$ curl  http://localhost:3333/articles
Forbidden


# member ロール
$ curl -H 'user_role:member'  http://localhost:3333/articles
[{"id":"1","user_id":100,"title":"Hi","slug":"hi","user":{"id":100,"name":"Peter","role":"collaborator"},"elapsed":10},{"id":"2","user_id":200,"title":"sup","slug":"sup","user":{"id":200,"name":"Julia","role":"collaborator"},"elapsed":10},{"id":"3","u
ser_id":300,"title":"alo","slug":"alo","elapsed":10},{"id":"4","user_id":400,"title":"bonjour","slug":"bonjour","elapsed":10},{"id":"5","user_id":500,"title":"whats up","slug":"whats-up","elapsed":10}]

$ curl -H 'user_role:member' -X DELETE http://localhost:3333/articles/1
Forbidden


# owner ロール
$ curl -H 'user_role:owner' -X DELETE http://localhost:3333/articles/1
{"id":"1","user_id":100,"title":"Hi","slug":"hi","user":{"id":100,"name":"Peter","role":"collaborator"},"elapsed":10}

$ curl -H 'user_role:owner' http://localhost:3333/admin
Forbidden


# admin ロール
$ curl -H 'user_role:admin' http://localhost:3333/admin
admin: index

ロールに権限があれば、操作が成功していることが分かります。

もっと細かい制御をするためには

上記の実装例だと、例えばある記事の削除は、作成したユーザー自身 も削除できるようにしたい、といった要望には対応できません（ユーザー単位でロールを作ればもちろん可能ですが、もはやそれはロールの意味が無いですよね）。

Casbinでどう実現するかですが、今のURLの構造でがんばるのであれば、articlesが追加されるごとにユーザーIDとマッピングさせた policy.csv のレコードに相当するデータを釣っていくことです。Casbinの機能であれば、Priority Modelで多段の権限を判定できるので、参考になるかもしれません。

また、この実装例のURL階層だと、ワイルドカードが使いにくいので、 /users/<user_id>/articles/<article id> といった階層を工夫すると policy のメンテナンスをシンプルに抑えることもできるかと思います。

まとめ

気になっていたCasbinの触りについてまとめました。ドキュメントサイトも新しくなっていますし、採用事例もちょくちょく聞きますし、プロダクション運用にも耐えうる品質だと思っています。

すこし気になっているのは、2022.10.3時点だと v3.0.0-beta.7 がタグ付けされています。もうすぐv3系がリリースされる予感があり、APIの互換性がすこし崩れるのかも？ と推測しています（とは言え、ドキュメントページも整理されていますし、すでにv1→v2で移行しているので、根本からそこまで変わらないのでは？ と思っていますが）。このあたりは新規に採用する時に留意したほうが良いと思います。

アクセス制限は自前で作り込むと面倒な割に、ユーザーからは当たり前品質の扱いをされがちだと思うので、こういった既存プロダクトにうまくのっかれると良いと思います。

参考

• https://qiita.com/unhurried/items/4688b4e94d96db2d1143
• https://articles.wesionary.team/understanding-casbin-with-different-access-control-model-configurations-faebc60f6da5
• https://zenn.dev/dove/articles/bc6933dbb39509

フューチャーで認証系のブログ連載と言えば、 Auth0 をテーマとした連載があります。今回は次のようにもう少しテーマを広くした連載を始めます。

• 認証・認可の技術全般
• WebAuthn、OpenID Connect 周り
• KeyCloack、Auth0、AWS Cognitoなどなんでも

2022年が初めてですので、「やってみた、触った見たレベルから」～「マニアックな挙動の紹介まで」何でもOKというテーマで募集したところ、5名が参加予定です。

フューチャーには「認証認可についての相談室」というGoogleチャットスペースがあり、そこで声掛けするとすぐに企画に賛同する人がいてくれて助かりました。

実はあまり活発ではないチャットルームなので、こうしたブログでの外部発表を通して交流を促進できると良いなとも感じています。

今回の連載で、少しでも皆様に良い情報を共有できればと思います！

アイキャッチ画像は、Arek Socha from Pixabayを利用させていただきました。

https://www.hanko.io/

このhankoのメンバーが運営しているpasskeys.ioというウェブサイトもあり、パスワードレスなログインを広めていこう！ という啓蒙サイトになっています。

https://www.passkeys.io/

この↑のサイトの存在を知らなかったのですが、@takuan_oshoさんからタレコミをいただきました。ありがとうございます。

動かし方

READMEに書いてある通りにdocker composeで一通り必要なものを起動します。

$ docker compose -f deploy/docker-compose/quickstart.yaml
   -p "hanko-quickstart" up --build

デモサーバーが8888で起動するのでブラウザでアクセスしてみます。登録アプリでは最終的に秘密ページ（secured.html）を表示しているのですが、そこに至るまでのフローがいろいろ選べます。

ユーザー登録をする（パスキーの登録あり、なし）フローと、登録後にログイン（メールに送られてくる6桁コード or 指紋認証）でした。AndroidのPixel 4aとmacでは指紋認証でしたが、きっとWindowsだと顔認証とかも機種によって選べるのかもしれません。手元のZephyrus G14はカメラ無しなので試せませんでしたが。

hanko自身はパスワード認証にも対応しているのですが、そのやり方はちょっとわからなかったです。まあhankoの目玉機能は一通り試せた感じです。YubiKeyを入れてみたけど登録手段としては表示されませんでした。READMEによるとまだYubiKey対応は開発中のようですね。

docker composeのシステム構成

サンプルプロジェクトのdocker-composeを見ると結構たくさんコンポーネントを使っています。こんなに全部必要なのか？ みたいに思ったので軽くみてみました。

• hanko-migrate
• hanko
• postgresd
• hankojs
• example
• mailslurper

このうち、hanko-migrateとhankoは同じイメージのオプション違いです。hankoサーバーがmigrateオプションを付けるとDBマイグレーションが起動するような仕組みになっているようです。DBマイグレーションで使っているライブラリは以下のやつでした。

• https://github.com/gobuffalo/fizz

postgresdはお馴染みのPostgreSQLです。対応しているデータベースは以下の4つです。

• CockroachDB
• MariaDB
• MySQL
• PostgreSQL

hankojsは<hanko-auth/>というカスタムタグのJavaScriptライブラリをビルドして提供するためのサービスとなっています。アプリ開発する場合はnpm install @teamhanko/hanko-elementsすればいいので、必須コンポーネントというわけではなさそうです。カスタムタグなのでLitを使っているのかと思ってコードを見てみたらpreact-custom-elementを使っていました。preact製でちょっと残念。マイクロフロントエンド的にカスタムタグを使うのは面白いですね。

mailslurperは開発時に便利に使えるメールサーバー＆クライアントでした。今まではメール機能の開発は面倒なものだと思っていましたがこれは便利ですね。上記のフローで6桁のコードが送られてくる時に、localhost:8080にアクセスするとメール一覧のビューアーが表示されるのでここで6桁コードが取得できます。

https://www.mailslurper.com/

いろいろコンポーネントがありましたが、JSはウェブフロントエンドにライブラリをバンドルしちゃえば不要ですし、DBとメールサーバーは本番環境ではSaaSサービスを使うでしょうし、マイグレーションは踏み台から起動すればいいだけなので、本番環境で起動すべきはhankoのバックエンドサーバーとアプリケーション本体だけでいけそうですね。

サンプルサーバーの実装

exampleはサンプルアプリケーションの本体です。ほとんど素のHTTPサーバーですが、ミドルウェアを1つ持っています。jwks.jsonをhanko本体のバックエンドサーバーから取得してきて認証の確認をしています。

func SessionMiddleware() echo.MiddlewareFunc {
	return func(next echo.HandlerFunc) echo.HandlerFunc {
		return func(c echo.Context) error {
			cookie, err := c.Cookie("hanko")
			if err == http.ErrNoCookie {
				return c.Redirect(http.StatusTemporaryRedirect, "/unauthorized")
			}
			if err != nil {
				return err
			}
			set, err := jwk.Fetch(context.Background(), "http://hanko:8000/.well-known/jwks.json")
			if err != nil {
				return err
			}

			token, err := jwt.Parse([]byte(cookie.Value), jwt.WithKeySet(set))
			if err != nil {
				return c.Redirect(http.StatusTemporaryRedirect, "/unauthorized")
			}

			log.Printf("session for user '%s' verified successfully", token.Subject())

			return next(c)
		}
	}
}

docker-compose.yamlのテクニック

今回サンプルを見てみて面白かったのはdocker-composeの書き方ですね。DBの待ち合わせとかどうしようか、リトライしておけばOK?みたいに今までやっていたのですが、このサンプルの書き方は良いですね。依存の順番に並べ替えて該当箇所だけ抜き出したのが以下のサンプルになります。

postgresd:
  healthcheck:
    test: pg_isready -U hanko -d hanko
    interval: 10s
    timeout: 10s
    retries: 3
    start_period: 30s
hanko-migrate:
  restart: on-failure
  depends_on:
    postgresd:
      condition: service_healthy
hanko:
  restart: unless-stopped
  depends_on:
    hanko-migrate:
      condition: service_completed_successfully

まずpostgresdではヘルスチェックを設定しています。DBマイグレーションはservice_healthyのpostgresdに依存、という書き方になっています。こういう書き方が可能なんですね。バックエンド本体はマイグレーションがservice_completed_successfullyの場合に起動となっています。マイグレーションと本体でそれぞれ一度起動なのかバッチなのかという違いがあるのでrestartの書き方が変えてあります。

まとめ

まだベータということですが、hankoを動かして、ちょっとコードを読んでみました。

パスワードレスなログインは今後はエンタープライズなシステムでも主流になっていくと思いますが、それをコンパクトに実装したhankoは良い学習素材になってくれそうです。

本番運用で使うには、ユーザー登録の管理画面とかいろいろ周りに用意してあげないといけない気もします。また、本番環境ではAuth0などのSaaSを使ってローカル開発環境ではこちら、みたいな使い分けとかもありかもしれませんが、そのような組み合わせの実現にもいろいろノウハウは必要そうですので、サンプルの起動は簡単でも導入にはちょっと工夫が必要な気がします。

また、新規に新しく作られているプロダクトはいろいろモダンなテクニックを知るのにも良いですね。特にdocker-compose.yaml周りの知識のアップデートになりました。

はじめに

はじめまして。2021年4月新卒入社、TIGの武田です。入社して早半年、最近開発の面白さに気付かされ、巷のエンジニアあるあるにも3割くらい共感できるようになりました。

私が参画した案件で、Auth0に登録されているエンドユーザ向けのアカウントを用いてShopifyにSSOする検証をしたので、今回はその方法をご紹介します。

SSOとは？

一度のユーザ認証をすると、以後そのユーザ認証に紐づけられているサービスを、追加の認証なしで利用できる機能です。
これにより、**ユーザはパスワードの記憶や管理の負担が減り、システム管理者はセキュリティ上の弱点を削減できます。

Auth0とは？

Auth0導入編をご参照ください。他にもAuth0関連の記事があります。

Shopifyとは？

本格的なネットショップが開設できるECプラットフォームで、世界NO. 1のシェアを誇っています。詳しくは公式サイトをご覧ください。

前提条件

実環境でSSO機能を利用するためには、ShopifyPlusのサブスクリプションが必要となります。また、Shopifyには無料の開発者向けの環境が用意されており、様々な機能をテストできます。今回は、開発者用ストアを使ってSSOを実装していきます。

Auth0のアカウントも必要になります。こちらも無料のものが提供されているので、今回はそちらを使います。

サンプル実装

マルチパスを利用して、Auth0アカウントでShopifyにSSOできるよう実装していきます。

目次

1. Shopifyアカウントでマルチパスを有効にする

2. Auth0アプリケーションを作成し、URIを設定する

3. Auth0ルールを追加して、マルチパストークンを作成する

4. ShopifyテーマにAuth0リンクを設定する

Shopifyアカウントでマルチパスを有効にする

Shopifyストアにログインし、 設定に移動して チェックアウトウィンドウをクリックします。顧客アカウントを、任意または必須に設定することで、ストアでマルチパスを有効にできます。

このシークレットキーはマルチパスリクエストが正当であることを確認するための暗号を作成するために使用されます。シークレットキーを再発行したい場合、マルチパスを無効にしてから再度有効にすることで、新たなシークレットキーが生成され、以前のものは無効化されます（上記画像のシークレットキーは既に無効化済みです）。

Auth0アプリケーションを作成し、URIを設定する

Auth0ダッシュボード内でApplicationsに移動し、Create Applicationをクリックして適当な名前を付け（「Shopify Store」など）、Regular Web Applicationsを選択し、CREATEします。

Settingsに移動します。

Application URIsを以下のように設定します。
{shopify-domain}は自身のストアのドメインに置き換える必要があります（例：sample-store.myshopify.com）

• Application Login URI：https://{shopify-domain}/account/login
• Allowed Callback URLs：https://{shopify-domain}/account
• Allowed Logout URLs：https://{shopify-domain}/account/logout

Advanced Settingsセクションを展開し、Application Metadataに次の2つのKeyとValueのペアを追加します。

• Key：shopify_domain ; Value：{shopify-domain}
• Key：shopify_multipass_secret ; Value：{multipass-secret}

Auth0ルールを追加して、マルチパストークンを作成する

Auth0ダッシュボードのAuth PipelineのRulesに移動して、Createを選択、templateはEmpty ruleを選択します。
わかりやすい名前（「ShopifyMultipass」など）を付け、次のコードを貼り付けます。

function (user, context, callback) {
  if (context.clientMetadata && context.clientMetadata.shopify_domain && context.clientMetadata.shopify_multipass_secret)
  {
    const RULE_NAME = 'shopify-multipasstoken';
    const CLIENTNAME = context.clientName;
    console.log(`${RULE_NAME} started by ${CLIENTNAME}`);

    const now = (new Date()).toISOString();
    let shopifyToken = {
      email: user.email,
      created_at: now,
      identifier: user.user_id,
      remote_ip: context.request.ip
    };
    if (context.request && context.request.query && context.request.query.return_to){
      shopifyToken.return_to = context.request.query.return_to;
    }

    const hash = crypto.createHash("sha256").update(context.clientMetadata.shopify_multipass_secret).digest();
    const encryptionKey = hash.slice(0, 16);
    const signingKey = hash.slice(16, 32);

    const iv = crypto.randomBytes(16);
    const cipher = crypto.createCipheriv('aes-128-cbc', encryptionKey, iv);
    const cipherText = Buffer.concat([iv, cipher.update(JSON.stringify(shopifyToken), 'utf8'), cipher.final()]);

    const signed = crypto.createHmac("SHA256", signingKey).update(cipherText).digest();

    const token = Buffer.concat([cipherText, signed]).toString('base64');
    const urlToken = token.replace(/\+/g, '-').replace(/\//g, '_');

   context.redirect = {
     url: `https://${context.clientMetadata.shopify_domain}/account/login/multipass/${urlToken}`
   };
  }
  return callback(null, user, context);
}

• 2行目：Auth0アプリケーションがshopify_domainとshopify_multipass_seceretのメタデータを保持しているときのみこのルールが実行されるようにします。
• 4〜6行目：ルールが実行されていることを確認するためのロギングです。
• 8-14行目：Shopifyには最低でもemailとcreated_atのデータが必要です。追加情報として、identifier（複数のAuth0アカウントが同じemailアドレスを持っている場合）、remote_ip（最初にログインリクエストを送信したコンピューターでのみこのマルチパスリクエストを使用できるようにする場合）を入れることができます。
• 15〜17行目：return_toクエリ文字列に値がある場合は、これをShopifyトークンに追加します。
• 19〜30行目：ここで実際に暗号化を行っています。GitHubのリポジトリを参照。
• 32〜34行目：これにより、認証されたユーザの宛先が設定されます。
  このルールが実行されると、ユーザはShopifyストアにリダイレクトされます。このルールの後にAuth0ルールがある場合、それらは完全にスキップされてしまうため、お気をつけください。

ShopifyテーマにAuth0リンクを設定する

Shopifyテーマを編集してログイン/ログアウトするためのリンクを追加していきます。
Shopifyストアの現在のテーマのコードを編集をクリックします。

まずは、ログインページを編集してログインリンクを追加します。Templatesフォルダ内のcustomers/login.liquidファイルを開き、リンクを追加するのに適した場所を見つけます。今回は、アカウント作成リンクの下に以下のリンクを配置します。

<a href="{{ settings.auth0_login_url }}">Log in with Auth0</a>

次に、アカウントページを編集してログアウトリンクをAuth0のログアウトリンクに置き換えます。Templatesフォルダ内のcustomers/account.liquidファイルを開き、ログアウトリンクを以下のリンクに置き換えます。テーマ内の他の場所にもログアウトリンクがある場合は、それも同様に置き換える必要があります。

<a href="{{ settings.auth0_logout_url }}">log_out</a>

続いて、ユーザがログインURLとログアウトURLを貼り付けることができるようにテーマ設定を追加します。Configフォルダ内のsettings_schema.jsonファイルを開き、以下のスニペットを配列の最後に貼り付けます。

ここでは、「Auth0 Config」という新しい設定セクションを作成し、ログインURLとログアウトURLを入力できるようにしています。idプロパティは、上記のリンクで使用したプロパティの名前と一致させる必要があります。

{
  "name": "Auth0 Config",
  "settings": [
    {
      "type": "text",
      "id": "auth0_login_url",
      "label": "Auth0 Login Url",
      "info": "The full Auth0 URL to redirect the customer to for login."
    },
    {
      "type": "text",
      "id": "auth0_logout_url",
      "label": "Auth0 Logout Url",
      "info": "The full Auth0 URL to redirect the customer to for logout."
    }
  ]
}

続いて、URLを作成していきます。
まずは、以下のようにログインURLを作成します。

上記で作成したAuth0アプリケーションのClient IDを取得します。

• auth0-instance：Auth0ドメイン（例：sample.jp.auth0.com）
• clientid：Auth0アプリケーションからの値。
• shopify-domain：自身のストアのドメイン。
• return-to-path：任意で返したいパスを設定可能（例：ログイン後にアカウントページに遷移させたい場合は、accountと設定）。

https://{auth0-instance}/authorize?response_type=code&client_id={clientid}&return_to=https://{shopify-domain}/{return-to-path}&scope=SCOPE&state=STATE

同様にログアウトURLも作成します。

• auth0-instance：Auth0ドメイン（例：sample.jp.auth0.com）
• clientid：Auth0アプリケーションからの値。
• shopify-domain：自身のストアのドメイン。

https://{auth0-instance}.auth0.com/v2/logout?response_type=code&client_id={clientid}&returnTo=https://{shopify-domain}/account/logout

テーマページに戻り、カスタマイズをクリックして、画面左下に出てくるテーマ設定をクリック、Auth0 Configセクションを展開して、作成したURLを貼り付けます。

以上で実装完了です！

実際の画面遷移

ログインページにて、Log in with Auth0をクリックする。

上記で作ったShopify StoreというAuth0アプリケーションの認証画面が出てくるので、認証情報を入力してログインする。

ログインに成功！

さいごに

最近ではSSOを利用できるサービスがかなり増えてきたなという印象ですが、実際使ってみると本当に便利ですよね。他のアプリケーションでもこのような方法でSSOを導入できると思いますので、導入を検討する際にはこちらの記事を参考にしていただけますと幸いです。

最後まで読んでいただきありがとうございました！

参考

• Authenticate Shopify Customers with Auth0 – Rovani in C#
• Authenticate Shopify Customers with Auth0 - Shopify - Pavilion
• Multipass | shopify.dev
• multipassify/multipassify.js at master · beaucoo/multipassify
• Auth0 Rule to Generate a Multipass token and redirect the user back to the Shopify store
• Shopify PlusでSSO（シングルサインオン） - Qiita
• Single Sign-On (SSO) For Shopify Using Auth0 as Identity Provider