AngularJS への改宗が完了した「mitsuruog」です。  
AngularJS に限らず Single page application(以下、SPA)を構築した場合、認証(Authenticate)とその後の WebAPI での証明情報(Credential)の受け渡し方法について最近悩んでいます。  
調べていたら Json Web Token(以下、JWT)を利用した方法が[Cookies vs Tokens. Getting auth right with Angular.JS](https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/)で紹介されていて、試してみると結構使えそうでしたので紹介してみます。



## 目次

## 1.WebAPI での証明情報の受け渡しの重要性

Web アプリケーションのフロントエンドを SPA で構築した場合、バックエンドへのアクセスは通常 WebAPI 経由になります。JSP 時代のようなフロントとバックが密結合した状態ではなく、SPA での WebAPI は一般的に広く公開されているものです。  
URL を知っていれば誰でもアクセスできる性質を持っています。(企業システムは VPN という閉じた世界で利用されることが多いもの事実ですが)

バックエンドではユーザ認証を行い、その証明情報を元に、不正なアクセスを除外したり、正しいアクセスに対して機能に対する認可を行わなければなりません。そのため、SPA での証明情報の受け渡しは非常に重要です。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2014/JWT2.png)

## 2.Token を利用した証明情報の受け渡し

まず、従来の Cookie を利用したやり方について簡単に説明します。ただし、「Token vs Cookie」のような関係ではなく、両者をうまく組み合わせた方がいいような気が今はしています。(ちょっと、まだ検証が足りてません)

Cookie を利用した証明情報とは「セッション ID」をイメージするいいと思います。この方法の特徴は、認証がバックエンドに依存していることです。つまり、バックエンド側では、認証された個人情報やロールをセッション ID に紐づけて保持する必要がありました。そのため、Web アプリケーションはセッションをどこで保持するかを意識した設計を行う必要がありました。

それに対し、Token を利用した方法では認証はバックンドに依存しません。ここでの「Token」とは「**電子署名**」の一種です。こちらが Token を利用した場合の証明情報の受け渡しフローです。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2014/JWT3.png)

まず認証後に、暗号学的ハッシュ関数(SHA-256 など)を使って暗号化した Token を生成して渡します。このときにロールや個人情報を Token に含めることがポイントです。  
フロントエンドは WebAPI アクセスする際に HTTP ヘッダーに Token を設定します。WebAPI アクセスを受けたバックエンドは Token を秘密鍵を使って復号し、Token が改ざんされていないことを確認することで、正しいアクセスであることを確認します。

Token には個人情報やロールが含まれているため、バックエンドにて認証の状態を保持する必要がありません。**同じ秘密鍵・暗号学的ハッシュ関数があれば異なるバックエンドであっても Token を受け入れることが可能**です。

これは、バックエンドがクラウド・オートスケールアップしていくような流れの中で、従来ようなセッションを意識しない証明情報の受け渡し方法として注目しています。

## 3.実現するためのコア技術、JWT(Json Web Token)とは

JWT とは、Json 形式の claims(※)を暗号化して URL で安全に送れるようにしたものです。

> (※)claims(クレーム)：うーん、いまいちイメージが湧かない。たぶん、上の個人情報とかロールとかそんな印象だと思います。

JWT の構造は JSON Web Signature(JWS)と JSON Web Encryption(JWE)の 2 つ。
(ちなみに上の[Cookies vs Tokens. Getting auth right with Angular.JS](https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/)は JWS です。)
JWS 構造の JWT を簡単に図解すると「ヘッダー」「クレームセット」「署名」の 3 部構成になっています。それぞれ Base64URL エンコードされており、署名はヘッダー・クレームセットから生成します。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2014/JWT1.png)

クレームセット部分には、個人情報やロールなどカスタム項目を設定します。これ以外に JWT の仕様で以下のような項目(クレーム名)が標準で定義されています。

- **iss:** Token 発行者
- **sub:** Token を利用するアプリケーション名など。(iss とセットで発行者側を識別するために使う)
- **aud:** この Token を利用することが想定される対象の識別子。例)このブログでの利用想定の場合は「blog.mitsuruog.info」のようになる(はず)
- **exp:** Token の有効期間
- **jti:** Token の一意性を保証するための ID を設定する

JWT についての詳細は下記のブログを参照してください。おそらく私よりかなり正確な理解をされていると思います。(JWT の日本語情報はかなり希少です)
特に hiyosi’s blog さんの記事は JWT の仕様と JWS 構造の JWT の作成・検証(ただし scala)まで含まれており、非常に有用です。

[JSON Web Token (JWT) - OAuth.jp](http://oauth.jp/blog/2012/10/26/json-web-token-jwt/)
[JWT について簡単にまとめてみた - hiyosi’s blog](http://hiyosi.tumblr.com/post/70073770678/jwt)

## 4.Token を利用した場合の課題など

Token を利用した場合の課題など、列挙しておきます。
私自身、どれだけ理解しているか不安ですので、ご意見いただけると嬉しいです。

### 秘密鍵の管理

JWT を利用した場合、その Token の正当性は暗号化する際の秘密鍵がすべてです。Token がフロントエンドで分散して保持されているため、なんからの方法で秘密鍵が外部に漏れてしまった場合の被害は甚大になると思われます。
スケールアウトしている場合など、秘密鍵の変更を素早く同期できる方法が必要です。

### リフレッシュトークン

おそらく、Token には何らかの有効期限を設けて運用すると思われます。Token の有効期限が切れた場合、Cookie を使っていた場合のセッションタイムアウトと同じ事態になりますので、OAuth2 のリフレッシュトークンのような仕組みが必要になると思います。
これは課題とではなく、やるべきことですね。できればその辺りまでライブラリでカバーして欲しいです。

### セキュリティ

Cookie の場合、CSRF、セッションハイジャックなどセキュリティ脆弱性がありました。Token を使った場合は、Cookie を利用していないため、Cookie の仕組みによる脆弱性はないと思われますが、他にどのような危険性があるかはまだ未知数です。(専門家の人助けてー)

特に、URL パラメータに Token 付与した場合とか、そもそも誤送信した時点でアウトなので、そもそもそのような利用シーンは想定しない方がいいか、などもう少し利用する上で検討しなければならない項目の見落としがありそうです。

## 5.まとめ

JWT を利用した証明情報の受け渡し方法いかがでしたでしょうか。
国内情報が少なくて、正直どこまで信頼できるか手探りの状態です。今後も引き続き WebAPI 周りの認証とか証明情報の受け渡しとか注視していきます。

最近、AngularJS で各ソーシャル対応の Token ベース認証ライブラリが出ましたので、こちらを使ってみるのもいいかと思います。
[sahat/satellizer](https://github.com/sahat/satellizer)

こちらが参考資料です。

- **Blog**
  - [Cookies vs Tokens. Getting auth right with Angular.JS](https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/)
  - [JSON Web Token (JWT) - OAuth.jp](http://oauth.jp/blog/2012/10/26/json-web-token-jwt/)
  - [JWT について簡単にまとめてみた - hiyosi’s blog](http://hiyosi.tumblr.com/post/70073770678/jwt)
- **仕様**
  - [JSON Web Token (JWT) draft25](http://self-issued.info/docs/draft-ietf-oauth-json-web-token.html)
  - [JSON Web Token (JWT) -日本語 draft11-](http://openid-foundation-japan.github.io/draft-ietf-oauth-json-web-token-11.ja.html)
- **ライブラリ**
  - [auth0/express-jwt(nodejs/express ミドルウェア)](https://github.com/auth0/express-jwt)
  - [auth0/node-jsonwebtoken(nodejs/JWS 形式の JWT 作成)](https://github.com/auth0/node-jsonwebtoken)
  - [sahat/satellizer(javascript/AngularJS 用の Token ベース認証ライブラリ)](https://github.com/sahat/satellizer)

JWT(Json Web Token)を利用したWebAPIでのCredentialの受け渡しについて

> How to internationalize the smart in OpenUI5/SAPUI5

エンタープライズ利用を想定した「[OpenUI5](http://sap.github.io/openui5/)」には、企業システムで有用な多くの UI コンポーネントを持っています。  
しかし、OpenUI5 の価値は豊富な UI だけではありません。OpenUI5 の本当の価値は、エンタープライズ利用を想定した HTML5 ベースのアプリケーションを作成するために、必要な機能を含んだオールインワンかつハイスペックな UI フレームワークということです。  
今回は、その中でも OpenUI5 が持つ強力な国際化機能について説明します。



![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2014/a1180_010361.jpg)

## 目次

本記事で利用するデモはこちらで参照出来ます。  
Demo here :).  
[http://mitsuruog.github.io/sapui5-showroom/app/#/locale](http://mitsuruog.github.io/sapui5-showroom/app/#/locale)

## 1. OpenUI5 での国際化

OpenUI5 にて国際化するための手順は「リソースモデルファイルの作成」「リソースモデルをロード」「コントロールへデータバインド」の 3 つです。
順に説明していきます。

### リソースモデルファイルの作成

まず、国際化用の「**リソースモデル(ResourceModel)**」を作成し、その中に国際化したいメッセージを定義していきます。ファイルはこちらを参考にしてください。

```
title = ロケール
text = 吾輩は猫である。名前はまだ無い。
changeLocale = ロケール変更:
button = これはボタンのテキスト
```

このリソースモデルは Java の「java.util.Properties」クラスと同等のもので、中に「key/value」ペアで値を設定していきます。ファイルの拡張子は「\*.properties」です。
（マルチバイトの場合であってもファイルが UTF-8 で作成されていれば、Unicode エスケープする必要はないようです。）

Web ルート直下に「i18n」フォルダを作成して、ファイルを配置するのが慣例のようです。まず、最低限ロケールなしの場合に利用される「**messageBundle.properties**」を作成します。各ロケールごとのファイル名の例は以下の通りです。

- messageBundle_en.properties
- messageBundle_ja.properties
- messageBundle_zh_CN.properties
- messageBundle_zh-Hans-CN.properties

ロケールの言語コードについての詳細はこちらを参照してください。

[Identifying the Language Code / Locale](https://openui5.hana.ondemand.com/#docs/guide/91f21f176f4d1014b6dd926db0e91070.html)

[言語の対応付け - Windows app development](http://msdn.microsoft.com/ja-jp/library/windows/apps/jj673578.aspx)

### リソースモデルをロード

次に、リソースモデルをアプリケーションにロードしていきます。こちらのコードを参考にしてください。

Locale.controller.coffee

```js

sap.ui.controller "com.mitsuruog.sapui5.showroom.view.Locale",

  onInit: ->
    i18nModel = new sap.ui.model.resource.ResourceModel
      bundleUrl : "i18n/messageBundle.properties"

    @getView().setModel i18nModel, "i18n"
```

ロードする場所は、「Component.js」の`init()`か、国際化対象 View の Controller の`init()`がいいと思います。`i18n`という名前付き Model としてロードして、後のコントロールへのデータバインドの際に利用します。

### コントロールへデータバインド

最後にコントロールの国際化したプロパティへメッセージをデータバインドしていきます。こちらのコードを参照してください。

Locale.view.coffee

```js
sap.ui.jsview "com.mitsuruog.sapui5.showroom.view.Locale",

  getControllerName: -> "com.mitsuruog.sapui5.showroom.view.Locale"

  createContent: (oController) ->
    @page = new sap.m.Page
      title: "{i18n>title}"
      subHeader:
        new sap.m.Bar
          contentRight: [
            new sap.m.Text
              text: "{i18n>changeLocale}"
          ]
      content: [
        new sap.m.Text
          text: "{i18n>text}"
      ]
      footer:
        new sap.m.Bar
          contentRight: [
            new sap.m.Button
              type: "Accept"
              text: "{i18n>button}"
          ]

    @page
```

こちらが国際化した結果画面の例です。日本語と英語で画面の項目名などが変化していることが分かると思います。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2014/Hello_SAPUI52_Fotor_Collage.png)

より詳細な内容は公式ページを参照してください。

[Step 4: Internationalization](https://openui5.hana.ondemand.com/#docs/guide/b6d1a9511f994b3a86e2f34a32e40a34.html)

[Translating SAPUI5 Applications](https://openui5.hana.ondemand.com/#docs/guide/91f217c46f4d1014b6dd926db0e91070.html)

## 2. ロケール判定の優先度

次に、OpenUI5 へのロケール指定の方法とロケール判定に優先度について説明します。こちらが一覧です。上から優先度が高い設定です。

- プログラムからの直接設定
- URL パラメータからの指定
- アプリケーション Config での指定
- window.navigator.userAgent での指定(Android のみ)
- window.navigator.language での指定
- window.navigator.userLanguage での指定(IE のみ)
- window.navigator.browserLanguage での指定(IE のみ)
- デフォルトのロケールは「**en**」

かなり細かい指定ですが、大きく分けると以下の 5 つになるかと思います。

- プログラムからの直接設定
- URL パラメータからの指定
- アプリケーション Config での指定
- 端末固有設定(window.navigator.language など)
- デフォルト「**en**」

この中で、プログラマブルに設定する可能性がある「プログラムからの直接設定」「URL パラメータからの指定」「アプリケーション Config での指定」について順に説明します。

### プログラムからの直接設定

プログラム上で OpenUI5 のロケール情報を参照する場合は、`sap.ui.getCore().getConfiguration().getLanguage()`を利用します。
ロケールの変更を行う場合は、`sap.ui.getCore().getConfiguration().setLanguage(local)`を利用します。引数の`local`にはロケールを文字列で設定してください。`null`を設定することはできません。

### URL パラメータからの指定

URL パラメータに`sap-language`を設定することでアプリケーション呼び出し時に特定のロケールを指定することができます。
こちらがその例です。

[http://mitsuruog.github.io/sapui5-showroom/app/?sap-language=en](http://mitsuruog.github.io/sapui5-showroom/app/?sap-language=en)

URL ハッシュが付く場合はこちらです。

[http://mitsuruog.github.io/sapui5-showroom/app/?sap-language=de#/locale](http://mitsuruog.github.io/sapui5-showroom/app/?sap-language=de#/locale)

### アプリケーション Config での指定

アプリケーション Config でロケールを設定することも出来ます。こちらは`sap.ui.core.Configuration`を利用するもので、詳細については割愛します。後日機会があれば別途取り上げたいと思います。

興味がある方はこちらの公式ドキュメントを参照してください。

[JsDoc Report - SAP UI development Toolkit for HTML5 - API Reference - sap.ui.core.Configuration](https://openui5.hana.ondemand.com/docs/api/symbols/sap.ui.core.Configuration.html)

## 3. まとめ

OpenUI5 での国際化の方法について説明しました。OpenUI5 はグローバルでの利用を想定した強力な国際化の機能を持っています。

このような国際化の仕組みは、OpenUI5 がエンタープライズ利用を想定したものであり、それを提供する SAP 社がグローバルカンパニーであるであるからこと出来たと考えています。  
簡単に国際化することができることも、OpenUI5 の魅力の一つですね。

August, 2014

JWT(Json Web Token)を利用したWebAPIでのCredentialの受け渡しについて

[SAPUI5/OpenUI5]スマートに国際化する方法