# 概要

個人開発をしよう、あるいは公開しようとおもっていつもぶち当たるのが認証である。

ここを完全に理解できていないせいで公開に至っていないというのも過言ではないくらい壁が厚い。そして高い。

逆に言えばここを掌握すれば公開に至るまでの道のりはベリーイージーである。
つまりどういうことかというと、やれということである。

基礎知識がないと追いかけるのも一苦労なので、足りない知識をここで補っていく。

## Cookie認証の大まかな流れ

基本的には、ユーザーのログイン状態をセッションとしてサーバー側で保管する。
フロントでは、ブラウザのクッキーにセッションのIDを保存する

1. ログインページからログイン情報を保存する
2. サーバーサイドで検証を行い、セッションに保存を行う。
3. 保存した後、セッションIDをブラウザに渡す。
4. ブラウザはクッキーに渡ってきたセッションIDを保存する。
5. 以降のリクエストにはセッションIDを含めたやり取りを行う。
6. セッションIDを元に「誰か」をサーバーサイドで特定し、それに応じたデータを返す。
7. ログアウトする場合は、サーバサイドとフロントのセッションを破棄する

 所謂ステートフルな通信というやつ

例えば、サーバーが複数あるような環境の場合、それぞれの環境でクライアント状態の同期をしなくてはいけないので、スケールアウトが難しい認証である。

## モバイルアプリケーションとトークンの認証

モバイルアプリの場合を考えてみる。
アプリの場合は、一般的な構成として、アプリ　＋　APIサーバー（or サーバーレス）の構成になる。
もしくはAPIGateWayを用いてRailsなどのフレームワーク（APIモード）と接続し、ハイブリッドで使用する。
モバイルアプリの場合は、ほとんどがトークン認証を行っている（と思う）。

## トークン認証の流れ

1. アプリ側から認証情報を送信する
2. 認証情報をサーバーサイドで検証し、トークンを作成する。
3. トークンをアプリに送信する。
4. 取得したトークンをアプリが受け取り、保存する
5. 以降のやり取りはトークンを含めてやり取りを行う。一般的にはAuthorizationヘッダーに埋め込む形を取る？
6. トークン付きのリクエストをサーバーで受け、検証を行う。


トークンの扱い方として、DBで保存を行ったり、トークン自体にユーザ情報（そのままはあれなのでここではJWTなどのことを言います。）を埋め込んだりしてそのまま送ることもあるみたい。

このへんはどういった方法で認証を行うかに依存した実装になる。

こういった認証機構を提供してくれるOAuthやOpenIDConnectなどはより詳しい情報が公式で提供されているので実際に使用する場合はドキュメント読むと幸せになれます。

詳細は当然として、クッキー認証とは異なる点ももちろんある。

トークン認証はシステム側で「セッション情報」というものを持たないので、クッキー認証に対して「ステートレス」な認証であると言える。

使用している側（ユーザー）からは違いはわからない。ログアウトする場合、クライアントサイドのトークンを削除することでログアウト処理とすることができる。

クッキー認証と違ってクライアントサイドに認証情報が用意されているので、スケールアウトしやすい構成ではあるが、検証にDBアクセスをする場合は毎回検証することになるのでそのあたりがネックになると思われる。

キャッシュなどを使用して検証をパスするような仕組みを実装する必要がでてきそう。


## 最近の構成

最近自分が関わっているプロダクトでは、構成としてRailsだけで完結するアプリケーションを作成することはほとんどなく、フロントにVueやReactを採用してSPAで構成するケースがほとんどになってきました。

部分的にコンポーネントを埋め込む構成もやっていたことがありますが、いろいろと辛みがでてきてしまい、どうせやるなら最初からSPAにしたほうがよくね？という流れができつつあります。
プロダクトの仕様としても動きのあるものが多いため、後々のことを見越してもSPAで作るのが現状ベターな選択肢です。

SPAの場合、上記で挙げたセッション認証/クッキー認証のどちらも採用することができる。
フロントエンドとバックエンドが分離されていない構成のアプリの場合は、ほとんどのケースでセッション認証を利用します。

一般的には、SPAとしてのページ以外に認証用のページを用意し、認証が終わった段階でSPAを表示するような流れです。
Railsでいえば認証基盤はDeviseに寄せて、それ以外はSPAという構成になります。
フロントとバックエンドが分離されている構成の場合は、トークン認証を使用するのが良さそう。

この場合、デプロイ先は別々になります。必然的にセッション認証を行うよりも、認証の実装は多少複雑になります。
利点としては、認証が一体化していないので、web -> モバイルという展開がローコストで実現できたりします。

とりあえずwebでファーストフェーズのリリースを行って、将来的にはモバイルアプリも～みたいな要件の場合は、トークン認証を採用してバックエンドとフロントエンドを分離して作成するのがとても良いと思います。

ただやはり初期の実装コストは一体型に比べると大きいのでPOと相談してビジネスサイドと合意した上で採用するか決めるのがよいです。
このような分離した認証のことをIDPって言うらしい。（Identity Provider）有名なのだとみんな大好き「Googleでログイン」とか。
自作する場合はAuth0とかが候補に上がってきそう。あと使ったことないけどAWSCognitoとかも

## 前提知識としての座学

### 認証と認可

ここがごちゃついてると今後の流れについてこれないかもしれないので改めて簡単に補足

認証というのは「お前はだれ？」ってやつです。~~運転免許証~~ 身分証です。
認可というのは、「許可される？」ってやつです。〇〇できる権限をもってるか？ということですね、

家の鍵をなくしたとします。扉に免許証を見せてもロックは外れません。一方、居住者でなくても、鍵さえ持っていれば「誰か」ということは関係なく家に入れてしまいます。つまりそういうことです。

英語では
- 認可 Authorization
- 認証 Authentication
と書きます。

このあたり混乱する原因として、認可の中にユーザー情報が入ってる場合に、それを認証として使えるっていうのがありそう。


今回はOAuth2を使って[認可]の仕組みを作っていきます。

## OAuth2

登場人物を整理してみる

- ユーザー ... あなた
- クライアント ... 認可を受けてアクセスするアプリ
- 認可サーバー ... 認可を管理する
- リソースサーバー ... 認可によってアクセスする先のサーバー

認可サーバーとリソースサーバーは同じサーバーを使っていることがほとんど。なので実質ユーザー、クライアント、認可サーバーの三個を覚えとけばいい。


### OAuth2　のトークン発行フロー

- Authorization Code Flow　... サーバーサイドで使う、一般的なやつ？
- Refresh Token Flow  ... アクセストークンを再発行するやつ
- Implicit Flow ... モバイルとか。アクセストークンがクライアントサイドから見れるので認証には使ってはいけない

### Authorization Code Frow 

多分よく見るタイプのやつ。「〇〇と連携しますか？」 -> 「XXからのリクエストを許可しますか？」 -> XXで〇〇からとってきた情報が表示されるみたいな流れのやつ。

連携を承認した場合、認可コードと呼ばれるものをブラウザに渡し、それをアプリが受け取り、アクセストークンを取得します。

認可コードはブラウザから見えますが、アクセストークンは直接見ることはありません。アプリはアクセストークンを利用してリソースサーバーから情報を取得し、適宜加工してブラウザに表示させます。

この時取得されるリソースからユーザー情報を取得し、認証を行うことで、認証も一緒に行うことができる。これがOAuth2の認証の流れ。

Implicit Flowの場合は連携の承認の後、認可コードを省略し、アクセストークンをブラウザに直接渡す。なのでトークンが見れてしまい、セキュリティホールになりうる。


### Reflesh Token Flow

アクセストークンは一度発行したら終わりというわけではなく、期限がついています。ずっと同じトークンが利用できてしまうとセキュリティ上都合良くないですね。

アクセストークンを取得する際に、リフレッシュトークンと呼ばれるアクセストークンを更新するためのトークンも取得することができます。

期限が切れた場合は、リフレッシュトークンを使用して、新しいアクセストークンを取得することで引き続き利用できます。

- Implicit Flowではリフレッシュトークンは取得できないので注意。むしろ取得できたらやばみ

### Implicit Flowで認証してはいけない理由

上２つで補足しているので大体わかってるとは思いますが、アクセストークンをユーザーが直接見れてしまうということは、「〇〇と連携しますか？～XXからのリクエストを許可しますか？」のフローをぶっ飛ばしてリソースを取得できる方法が取れてしまうということです。

対策としては、
- アクセストークンの発行対象を確認するようにする
- OpenID Connectのトークンを使用する

などして、「このトークンはどのアプリに対して発行されたものなのか？」を判別することです。ただ、この仕組みはOAuth2では提供されてないっぽいので、ここでOpenID Connectのトークンを使うことになります。

なので結論現状ではOAuth2の　Implicit Flowのみで認証を行うのは非推奨扱いになってると思われる。

## OpenID Connect 

ちょこちょこ名前が出てきたOpenID Connectについても見ていく。
OpenID ConnectはOAuth2とは異なり、認証の仕組みを提供する仕様。

```txt
OpenID Connect = OAuth2(認可の仕組み) + 認証
```

と表現されてるとこが多い。

OpenID Connectを利用することで、「誰向けのトークンなのか？」という判別ができるようになり、Implicit Flowであったような脆弱性に対応できます。

フロントとバックの分離したアプリなどでフロントエンドで認証を行う場合はこれを使用するのが良さそう。

OpenIDの特徴として、IDTokenというものが使えるようになる。

## OpenIDの発行フローを見ていく

OpenID Connectの発行フローとしては、response_type, scopeの組み合わせで決まる。
認可コード + アクセストークン + IDトークンの組み合わせ、あるいはnoneを指定できる。

クライアントサイドで認証認可を行いたい場合は、アクセストークン（token）と、IDトークン(id_token)を取得するように実装する必要がある。

また、それとは別に、認可エンドポイントとトークンエンドポイントの２つから何が取得できるのかを指定することができる。


今回の場合は認可エンドポイントから、アクセストークンと、IDトークンを取得する。IDトークンの中には、「誰向け？」「有効期限」「発行者はだれ？」という情報が入っています。（JWT）

このIDトークンを利用して、各バックエンドサーバーにアクセスする。バックエンドではIDトークンを検証して、レスポンスを返す。

## JWT(JSON Web Token)

### ジョット

大事なことなので最初に言いますが、JWTはジョットとよみます。ここテストに出るので忘れないように。

JWTは２者間で安全に情報を伝達するためのトークンである。
含まれている情報はデジタル署名しているので、改ざんできません。（したらわかるよ）

発行者と発行者保有する情報を持っている者だけがチェックできる。共通鍵とか公開鍵とかのあれ。

JWTは「署名」であって「暗号化」ではないのでユーザー情報が入ってる場合、閲覧自体はだれでもできる。

暗号化のオプションもあって、　JSON Web Encryption（JWE)というらしい。

また、サイズが小さいことも特徴の一つ。
URLやPOSTパラメーター、ヘッダーに入れて送信することができる。

### JWTの中身

JWTはドット(.)で区切られていて、３要素から成り立っています。

1. Header
2. Payload
3. Signature

順番も上記の順でドットでつながっている。
例で言うと
hogehoge.hugahuga.piyopiyo

Header = hogehoge
Payload = hugahuga
Signature = piyopiyo

https://jwt.io/
ここで検証するのがおすすめ

#### Header

ヘッダーの中身はトークンの種類と、アルゴリズムが記載されている。
```json
{
    "alg": "H256",
    "typ": "JWT"
}

```

#### Payload
ペイロードにはキーと値のペア情報の形で色々なデータを詰め込めます。ユーザー情報とかもここで入れます。Claim（クレーム）っていうらしい。

```json
{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}
```
iss => Issuer。発行者のこと。Googleとか。
sub => Subject。誰を認証したのか？という情報。UserId1の人とか。
aud => Audience。利用者のこと。自分のアプリ。
nonce　=> Number Used Once リプレイアタック対策の文字列 

#### Signature

ヘッダーとペイロード、シークレットを組み合わせたもの。改ざんされていないかどうかを検証するために使われる部分。


### JWTのフロー
Googleログインを例にあげます。


1. Googleでログインをクリックする
2. ログインしたら、JWTが返ってくる
3. JWTをローカルストレージとかクッキーなどに保存する
4. ヘッダーにJWTを埋め込んでアプリにリクエストを飛ばす
5. JWTを読み取って改ざんされていないかを確認する
6. 問題なければJWTの中のユーザー情報を使用して処理する

3の、ローカルストレージ vs cookieはどっちがいいのかわからない。

ローカルストレージの場合は、同一生成元ポリシーによって保護されている。cookieに保存する場合はなんか対策が必要そう。

それとは別途XSSの危険性もあるので、そこは気をつける。Railsであればhtml_safeとかしない限りはフレームワークが守ってくれたりするので、対策しましょう。VueとかReactも対策してくれていますが
```dangerouslySetInnerHTML````とかするところは注意しましょう。

[Vue セキュリティ](https://jp.vuejs.org/v2/guide/security.html)

コード書いてないけど長くなったので一旦ここまで。


Auth0を使いこなす~基礎知識編~

#　Nuxtで認証認可をやる

[前回の続きから](https://saboten.dev/posts/auth0-for-spa-app-1)

jwtと認証認可の基礎知識を学んだので、実際に動かしてみる。
このブログはNext.jsで作っているが、今回はNuxtを使ってやってみる。

nuxt-community　には、認証系のモジュールのテンプレートや、大体のアプリケーションに必須な機能がデフォルトで組み込まれているテンプレートが存在し、それらを使用することで基本機能の実装はスキップできる。

https://github.com/nuxt-community/auth-module
https://github.com/nuxt-community/typescript-template

今回はnuxt/authモジュールは使わず、一方でtypescriptを使いたいので、スターターキットから下記のテンプレートを拝借します。

https://github.com/nuxt-community/typescript-template

いつもどおりyarnして起動準備。

とりあえず名前は `nuxt-auth-spa-sample` としておきました。~~長い~~

```sh
yarn dev
```
すると起動します。

## 事前準備

Auth0を組み込む前に準備をします。


### ポート番号を変更する
まずはポート番号を変えておきましょう。バックエンドにRailsを使う予定なので、そのままだとポート番号の3000が被ってしまいます。
番号は他とかぶらなければ何でも良いので、今回は5000とかにしました。

デフォルトのポート番号を変更するために、pacage.jsonのdevの部分にオプションを付け足します。

```ts
"dev": "HOST=0.0.0.0 PORT=5000 nuxt"

```

変更したら、指定したポートで開いて確認します。

### SPA設定する

nuxtでspa設定するのは簡単で、nuxt.config.tsファイルにssrオプションを設定するだけで完了する。

```ts
ssr: false
```
modeというオプションもあるが、こちらは現時点で非推奨になっている。


デフォルトでもnuxtはnextと違ってnuxt.configファイルを変更しても再起動を自動でしてくれるみたい。

これで一旦フロントの最低限の設定はできたので、Auth0を組み込んでいく。


## Auth0を使う準備をする

nuxtには専用のauthモジュールがあるので、実際にアプリケーションを作成する事となった場合、それらを採用するのが良さそう。

今回はフレームワーク専用のモジュールを使わずに実装してみたいので、Auth0を適用できる通常のライブラリを使用する。
サラッと調べたところ、auth0をjsで使用するには大きく2つ選択肢があるっぽい。

- auth0-js
- auth0-lock

auth0-jsはカスタマイズ性の高いライブラリっぽい。auth0-lockは最初からフォームを組み込んでくれているラッパーといった感じ。

フォームをカスタマイズしていくのは必要になってくる事が多いが、今回は本題とそれるのでlockを使って組み込みのフォームを利用させてもらおう。


```sh
yarn add  auth0-lock  @types/auth0-lock
```

その後、plugins以下にauth0.tsというファイルを作成し、下記のように記載。

```ts
import Auth0Lock from 'auth0-lock'
import nuxtConfig from '~/nuxt.config'

const config = nuxtConfig.auth0

class Auth0Util {
  showLock(container: any) {
    const lock = new Auth0Lock(config.client_id, config.domain, {
      container,
      closable: false,
      auth: {
        responseType: 'token id_token',
        redirectUrl: this.getBaseUrl() + '/callback',
        params: {
          scope: 'openid profile email',
        },
      },
    })

    lock.show()
  }

  getBaseUrl() {
    return `${window.location.protocol}//${window.location.host}`
  }
}

export default (context: any, inject: (arg0: string, arg1: Auth0Util) => void) => {
  inject('auth0', new Auth0Util())
}

```
client_idはキャメルケースにすると怒られたのでスネークケースにしてる。


### 環境変数で渡す

Auth0のClientIDなどをconfigに書いていきたいが、そのまま直打ちすると流出してしまう恐れがあるので環境変数経由で見るようにしたい。

https://ja.nuxtjs.org/docs/2.x/configuration-glossary/configuration-env/

`NUXT_ENV`で始まる環境変数を定義すれば、ビルドフェーズで値が自動的に注入されるとのこと。

その他に、dotenvモジュールを入れる方法もあり、今回はこっちを使っていく。

```sh
 yarn add -D @nuxtjs/dotenv    
```

インストールしたら、nuxt.config.tsのモジュールに追加して使えるようにします。


```ts
modules: [
    '@nuxtjs/dotenv'
  ],
```

そして、auth0の情報もnuxt.config.tsに追加します。

```ts
auth0: {
    domain: process.env.AUTH0_DOMAIN,
    client_id: process.env.AUHT0_CLIENTID
  }
```

全体像はこんな感じになった

```ts
import type { NuxtConfig } from '@nuxt/types'

const config: NuxtConfig = {
  build: {},
  buildModules: [
    '@nuxtjs/composition-api',
    '@nuxt/typescript-build'
  ],
  ssr: false,
  css: [],
  env: {},
  head: {
    title: 'nuxt-community/typescript-template',
    meta: [
      { charset: 'utf-8' },
      { name: 'viewport', content: 'width=device-width, initial-scale=1' },
      { hid: 'description', name: 'description', content: 'A boilerplate to start a Nuxt+TS project quickly' }
    ],
    link: []
  },
  loading: { color: '#0c64c1' },
  modules: [ '@nuxtjs/dotenv'],
  plugins: [
    '~/plugins/auth0',
    '~/plugins/truncate'
  ],
  auth0: {
    domain: process.env.AUTH0_DOMAIN,
    client_id: process.env.AUHT0_CLIENTID
  },
  
}

export default config

```

### Loginページを作る

基本機能はできたので、loginページを作る。
`pages/login.vue` というファイルを作成し、ログイン用のAuth0のフォームが出てくるようにする。


```vue
<template>
  <div id="show-auth"></div>
</template>

<script>
  export default {
    setup() {},
    mounted() {
      this.$auth0.showLock('show-auth')
    },
  }
</script>

```

~~composition-api?知りませんねぇ。~~

![スクリーンショット 2021-03-08 184112.png](https://media.graphcms.com/airJHl3bSYKt7QHfPpGS)

上記のようにフォームが出てこればおｋ。

ここでloginしてみてもいいが、エラーになる。

nuxt側でcallbackに対応するページを作成することと、Auth0側で「Allowed Callback URLs」「Allowed Web Options」の2つを許可してあげる必要がある。

開発環境なので、localhostと開けてるポート番号を登録する。今回はnuxt用の5000と、Railsで使用する3000を開けた。

```ts
<template>
  <p>callback</p>
</template>

<script>
  export default {}
</script>

<style></style>

```

これらの設定をすべて整えた上でGoogle ログインを選択してみる。


googleでログインを済ませると、callback.vueファイルにリダイレクトする。

リダイレクトしたら、URL欄を見てみる。localhost:xxxx/callbackの後ろに膨大な文字列がくっついてくる。

これはauth0で取得したトークン群である。
access_tokenやid_token,expire_atなど色々ついてきているが、ここではid_tokenを見ていきたい。


id_tokenはjwtである。ここでは、auth0.tsのスコープに指定した情報が入っている。

jwt.ioでトークンを複合してみる。
urlからid_token以下の文字列を抜き取り、jwt.ioに貼り付け。

![スクリーンショット 2021-03-08 185510.png](https://media.graphcms.com/SJ81b7uRxOozGrbTaLRg)

みたいに自分のログイン情報が表示されていればオッケー。

## トークンの保存

現状だとただURLに返ってきただけなので、それを使って色々できていない状態。とりあえずSPAで必要な情報をLocalStrageに保存したい。

```sh
yarn add jwt-decode query-string @types/jwt-decode @types/query-string    
```

jwtのデコードを行えるライブラリと、クエリパラメータをいい感じに取得できるライブラリを追加。

追加できたらauthutilに保存処理用のメソッドを書いていく。

```ts
import Auth0Lock from 'auth0-lock'
import nuxtConfig from '~/nuxt.config'
import jwtDecode from 'jwt-decode'
import queryString from 'query-string'

const config = nuxtConfig.auth0

class Auth0Util {
  getQueryParams() {
    return queryString.parse(location.hash)
  }

  setTokenToLocalStorage({ access_token, id_token, expires_in }: any) {
    const localStorage = window.localStorage
    localStorage.setItem('accessToken', access_token)
    localStorage.setItem('idToken', id_token)
    localStorage.setItem(
      'expiresAt',
      (expires_in * 1000 + new Date().getTime()).toString()
    )
    localStorage.setItem('user', JSON.stringify(jwtDecode(id_token)))
  }

  setTokenByQuery() {
    this.setTokenToLocalStorage(this.getQueryParams())
  }

  showLock(container: any) {
    const lock = new Auth0Lock(config.client_id, config.domain, {
      container,
      closable: false,
      auth: {
        responseType: 'token id_token',
        redirectUrl: this.getBaseUrl() + '/callback',
        params: {
          scope: 'openid profile email',
        },
      },
    })

    lock.show()
  }

  getBaseUrl() {
    return `${window.location.protocol}//${window.location.host}`
  }
}

export default (
  context: any,
  inject: (arg0: string, arg1: Auth0Util) => void
) => {
  inject('auth0', new Auth0Util())
}

```

localStrageにurlをparseして各情報を入れていく。

定義し終わったら、urlに情報が入ってくるcallback.vueに呼び出す処理を追加する。

```ts
<template>
  <p>callback</p>
</template>

<script>
  export default {
    mounted() {
      this.$auth0.setTokenByQuery()
    },
  }
</script>

<style></style>

```
このようにすることによって、callbackがマウントされたときにlocalStrageに値を入れることができる。

![スクリーンショット 2021-03-08 223341.png](https://media.graphcms.com/rCoE3WMRAC4QaWBYSmUI)


確認できたら、ログイン後にはトップページにリダイレクトするようにしておこう。

```ts
 this.$router.replace('/')
```

nuxtの場合は、上記の一行でルートを変更できる。

## ログイン状態を判定する

トップページに遷移した後、今ログインしているのかどうかを知りたい。
Auth0のデフォルトだと、アクセストークンの有効期限は２時間、jwtの有効期限は10時間となる。

今回はアクセストークンが有効期限なのかどうかを判定するようにしてみる。

```ts
isAuthenticated() {
    const expiresAt = window.localStorage.getItem('expiresAt')
    if (!expiresAt) {
      return false
    }
    return new Date().getTime() < Number(expiresAt)
  }
```

expiresAtはログインしていない状態だとnullになるので、その場合はfalseを返すようにしておきます。


```ts
 isAuthenticated(): boolean {
    const expiresAt = window.localStorage.getItem('expiresAt')
    if (!expiresAt) {
      return false
    }
    return new Date().getTime() < Number(expiresAt)
  }

```

boolean型を返すので、v-ifで分岐して使えるようになった。この分岐を使用して、loginしているときだけユーザー情報を表示したいと思う。
表示するのはnicknameをとりあえず表示し、その後必要な情報があれば追加で出すことのできる状態にする。

```ts
getUserData() {
    const userString = window.localStorage.getItem('user')
    return userString ? JSON.parse(userString) : null
  }

```

index.vueに分岐と、定義した２つのメソッドを使用できるようにする。

```ts
<template>
  <main>
    <div v-if="!loggedIn()">
      <div>ログインしてください。</div>
      <nuxt-link class="button is-primary" to="/login">
        <span>login</span>
      </nuxt-link>
    </div>
    <div v-else>
      <div>{{ userInfo().nickname }}</div>
    </div>
  </main>
</template>


<script lang="ts">
export default {
  methods: {
    loggedIn() {
      return this.$auth0.isAuthenticated()
    },
    userInfo() {
      return this.$auth0.getUserData()
    }
  }
}
</script>

```

## ログアウトできるようにする

ログアウトもできるようにしておく。ログアウトはローカルストレージに保存されたデータをクリアすることで、ログアウト扱いになる。（isAuthenticated()メソッドがfalseになる）


```ts
logOut() {
    const localStorage = window.localStorage
    localStorage.removeItem('accessToken')
    localStorage.removeItem('idToken')
    localStorage.removeItem('expiresAt')
    localStorage.removeItem('user')
  }

```
clearすると既存のlocalstrageのデータが全部消えてしまい、他のアプリにも影響が出たりするかもしれないので、一個づつ消した。

ログアウトボタンは、ログイン済みの場合に表示し、ボタンを押したらログアウト処理+topページにリダイレクトするようにする。

index.vueに追加。

```ts
<div v-if="!loggedIn()">
      <div>ログインしてください。</div>
      <nuxt-link class="button is-primary" to="/login">
        <span>login</span>
      </nuxt-link>
    </div>
    <div v-else>
      <div>{{ userInfo().nickname }}</div>
      <button @click="logout()">
        ログアウトする
      </button>
    </div>
    ...
    <script>
    ....
     logout() {
      this.$auth0.logOut()
      this.$router.replace('/')
    }
    ....
    </script>
    
    
```

### アクセストークンを使用して、ユーザー情報を取得する


現状、localStrageのUserキーでユーザー情報を格納しているので、そこから情報を取得することはできたが、本来は取得したaccess_tokenを使用して、リソース元から情報を取得するのが普通である。

APIへのアクセスには、AuthorizationヘッダーのBearerスキームというものを使用する。
保護された情報にアクセスしたい場合、ヘッダーにアクセストークンを付与する。

簡単に確認したい場合はcurlかPostmanのようなアプリを使用するのが良い。

curlの場合は、

```sh
 curl -H "Authorization: Bearer アクセストークン" https://<Auth0のテナント名>.auth0.com/userinfo
```
みたいな感じで試すとよい。　


フロントの認証のベースはできたので、次回はバックエンド側を実装してみる。


Nuxt.jsとAuth0で学ぶ認証認可~front編~

##
前回で基本的なAPI通信の基礎はできたので、今回は認証付きのAPIアクセスをやってみる。
具体的には、Auth0からもらった公開鍵を使用して、nuxtから送られてきたjwtを検証する。

## 認証に何使うか？
通常Railsで認証を行う場合、deviseやらsorceryやらを使用することが多いです。
今回はSPAということもあり、別の選択肢が候補に上がります。firebaseを使うパターンもありますが、今回はKnockを使ってみたいと思います。

https://github.com/nsarno/knock

KnockはRails Apiモードに特化したステートレスなセッションを行いたい場合に選択肢に上がる事が多いです。トークンの管理は今回Auth0に任せたいので、そのあたりも相性が良さそうです。


### RailsアプリにKnock入れる

Rails側にknockを入れていきます。環境変数も入れたいので、ついでにdotenvも導入します。


今回はKnockを採用しましたが、ruby-jwtというgemもあり、そちらのほうが更新頻度も多いのでそっちを使ったほうがいいかも
https://github.com/jwt/ruby-jwt



Gemfile
```rb
gem "knock"
gem "dotenv-rails"
```

Knockを入れると、コマンドで設定ファイルを作成できるようになるので、下記生成する。

```sh
rails g knock:install
```

実行するとconfig/initializers/knock.rb が生成される。この設定ファイルを今回の要件に対応させるように書き換える。

参考
https://rwehresmann.medium.com/ruby-on-rails-auth0-knock-7f114ed87e4b


```rb
require "net/http"
require "knock/version"
require "knock/authenticable"

Knock.setup do |config|

  ## Expiration claim
  ## ----------------
  ##
  ## How long before a token is expired. If nil is provided, token will
  ## last forever.
  ##
  ## Default:
  # config.token_lifetime = 1.day

  ## Audience claim
  ## --------------
  ##
  ## Configure the audience claim to identify the recipients that the token
  ## is intended for.
  ##
  ## Default:
  config.token_audience = -> {ENV['AUTH0_CLIENT_ID']}

  ## If using Auth0, uncomment the line below
  # config.token_audience = -> { Rails.application.secrets.auth0_client_id }

  ## Signature algorithm
  ## -------------------
  ##
  ## Configure the algorithm used to encode the token
  ##
  ## Default:
  config.token_signature_algorithm = "RS256"

  jwks_raw = Net::HTTP.get URI(ENV['AUTH0_JWKS'])
  jwks_keys = Array(JSON.perse(jwks_raw)["keys"])

  ## Signature key
  ## -------------
  ##
  ## Configure the key used to sign tokens.
  ##
  ## Default:
  # config.token_secret_signature_key = -> { Rails.application.secrets.secret_key_base }

  ## If using Auth0, uncomment the line below
  # config.token_secret_signature_key = -> { JWT.base64url_decode Rails.application.secrets.auth0_client_secret }

  ## Public key
  ## ----------
  ##
  ## Configure the public key used to decode tokens, if required.
  ##
  ## Default:
  config.token_public_key = OpenSSL::X509::Certificate.new(Base64.decode64(jwks_keys[0]["x5c"].first)).public_key

  ## Exception Class
  ## ---------------
  ##
  ## Configure the exception to be used when user cannot be found.
  ##
  ## Default:
  # config.not_found_exception_class_name = 'ActiveRecord::RecordNotFound'
end

```

AUTHO0_JWKSにはAuth0の公開鍵情報を取得できるurlを設定します。この公開鍵を用いて、JWTを検証します。

## Userモデルを作る

Rails側にログインしたらユーザー情報を保存したいので、ユーザーモデルの作成を行います。
現状はemailアドレスとどんな媒体でログインしたかを知りたいので、emailとsubのカラムを追加します。それ以外でももし欲しい情報があればカラムを用意して保存できるようにすると良いでしょう。

```
rails g model User email:string sub:string
rails db:migrate
```

マイグレーションができたら、UserモデルにKnockの認証用のメソッドを定義していきます。


```rb
class User < ApplicationRecord
  def self.from_token_payload(payload)
    find_by(sub: payload["sub"]) || create!(sub: payload["sub"], email: payload['email'])
  end
end

```
Knockを適用した範囲のAPIでは、自動でfrom_token_payloadというメソッドが呼ばれる。このメソッドの第一引数に、JWTのペイロードが入ってくる。

また、適用したAPIの範囲と言っているように、APIにKnockを使用することを明示してあげます。
ApplicationControllerに入れておきましょう。

```rb
class ApplicationController < ActionController::API
  include Knock::Authenticable
end

```

ここまでできたら、認証付きのAPIコントローラーを設定します。今回はauth_controller.rbという名前にしました。

```rb
module Api
  module V1
    class AuthController < ApplicationController
      before_action :authenticate_user

      def index
        render json: {
          message: "ID : #{current_user.id}, SUB: #{current_user.sub} ",
        }
      end
    end
  end
end

```

ルーティングも変更。

```rb
Rails.application.routes.draw do
  namespace :api do
    namespace :v1 do
      resources :hello
      resources :auth
    end
  end
end

```

```rb
before_action :authenticate_user
```

を行っているので、authコントローラーにだけauthorizeするようにしています。
この状態でauthにアクセスしても、401が返ってきます。

ポストマンやcurlを用いてBearerにid_tokenを入れて検証してみます。
戻り値として、authコントローラーで指定した形で値が取得できればOKです。

```json
{"message":"ID : 6, SUB: google-oauth2|hogehogefugafuga "}
```

## Nuxtから呼べるようにする

最後に、フロントエンド側から、この情報を取得できるようにしておきます。

id_rokenを検証にわたしてあげたいので、LocalStrageからid_tokenを抜き出すメソッドを定義します。

auth0.ts
```ts
getIdtoken () {
    return this.isAuthenticated() ? localStorage.getItem('idToken') : null
  }
```

ログインしていればローカルストレージからidTokenを取得し、そうでないならnullを返すようにします。

index.vueにも、auth用のボタンを置きましょう。
全体像はこうなりました。

index.vue
```ts
<template>
  <main>
    <ul>
      <li
        v-for="page in ['Options API', 'Class API', 'Composition API']"
        :key="page"
      >
        <nuxt-link
          :to="
            `/${page
              .toLowerCase()
              .split(' ')
              .join('-')}`
          "
        >
          With {{ page }}
        </nuxt-link>
      </li>
    </ul>
    <div v-if="!loggedIn()">
      <div>ログインしてください。</div>
      <nuxt-link class="button is-primary" to="/login">
        <span>login</span>
      </nuxt-link>
    </div>
    <div v-else>
      <div>{{ userInfo().nickname }}</div>
      <button @click="logout()">
        ログアウトする
      </button>
    </div>
    <div>
      <button @click="greet()">
        挨拶する
      </button>
    </div>
    <div>
      <button @click="auth()">
        authする
      </button>
    </div>
  </main>
</template>

<script lang="ts">
export default {
  methods: {
    loggedIn () {
      return this.$auth0.isAuthenticated()
    },
    userInfo () {
      const user = this.$auth0.getUserData()
      console.log(user)
      return user
    },
    logout () {
      this.$auth0.logOut()
      this.$router.replace('/')
    },
    async greet () {
      const ret = await this.$axios.$get('/api/v1/hello')
      console.log(ret)
    },
    async auth () {
      const data = await this.$axios.$get('/api/v1/auth', { headers: { Authorization: 'Bearer ' + this.$auth0.getIdToken() } })
      console.log(data)
    }
  }
}
</script>

```

この状態で、authボタンを押すと、console.logによってapi/v1/authにアクセスした結果のidとsubが返ってきています。

![スクリーンショット 2021-03-10 025017.png](https://media.graphcms.com/PBqkKGWGSXqemuKve6aV)

これで、フロントでAuth0を用いてログイン、バックエンドアプリでid_tokenを使った検証、検証データをフロントでっ取得するという流れができました。
本番で運用する際は、ログイン後の画面に関しては共通のヘッダーを設定したり、検証したデータでリソースの表示を行ったりなど、色々やることはありますが、仕組みがいい感じにわかったので今回はここまでにします。


Nuxt.jsとAuth0で学ぶ認証認可~つなぎ込み~

## OAuth is 何

OAuth2.0の標準仕様であるRFC6749を見る。

> OAuth 2.0 は, サードパーティーアプリケーションによるHTTPサービスへの限定的なアクセスを可能にする認可フレームワークである. サードパーティーアプリケーションによるアクセス権の取得には, リソースオーナーとHTTPサービスの間で同意のためのインタラクションを伴う場合もあるが, サードパーティーアプリケーション自身が自らの権限においてアクセスを許可する場合もある. 本仕様書はRFC 5849に記載されているOAuth 1.0 プロトコルを廃止し, その代替となるものである.

OAuthを理解するために必要な用語がいくつかある。
- サードパーティーアプリケーション（クライアント)
- HTTPサービスへの限定的なアクセス
- 認可フレームワーク
- リソースオーナー
- 認可サーバー
- リソースサーバー

をイメージしやすいように具体例を交えて理解していく。

前提として、ユーザーの許可によってGoogleDriveにある画像をダウンロードし、加工するアプリを例に出す。

#### サードパーティアプリケーション
これは画像の編集アプリを指す。開発者にとっては作成中のアプリであることが多い。「サードパーティ」というのは、後述するHTTPサービスから見た場合に「第三者」であるから。

#### HTTPサービスへの限定的なアクセス
HTTPサービスはGoogleDriveのこと。限定的なアクセスというのは、GoogleDriveにあるデータにどんな操作でもできるというわけではないということ。例えば、このアプリでは、GoogleDriveへのアップロードなどは許可されていないとする。その意味で、限定的なアクセスになるということ。

補足ですが、Driveにある画像は、Driveのものではなく、後述するリソースオーナーの所有であるという考え方をします。なので、サードパーティアプリに対しての許可は基本的にはリソースオーナーの許諾がないと行えないという流れになっている。

#### 認可フレームワーク
OAuthのこと。アクセストークンの発行に関してのルールであり、ここでいうと、そのルールに従ってGoogleのOAuthが行われる。

#### リソースオーナー
リソースオーナーはユーザーのこと。スマートフォンなどの場合は、その本体がリソースオーナー（の物）であるとして、その本体経由であれば自動的に許諾扱いになるものもある。

#### 認可サーバー
認可サーバーはアクセストークンを発行するためのサーバーのこと。GoogleのAuth
が該当します。

#### リソースサーバー
リソースサーバーはWebAPIに代表されるもの。リクエスト -> 欲しい情報が来る（今回でいうところの画像データ)
認可サーバとリソースサーバーは兼務されていることも多い。

#### クライアントタイプ
上記ではクライアントはサードパーティアプリケーションと同一視して扱ったが、OAuthとして「クライアントタイプ」という用語があるのでそちらを別途補足する。
OAuthでは、クライアントの認証情報であるクライアントID,クライアントシークレットをセキュアに保存できるかどうかでクライアントタイプを定義している。
セキュアに保存できる場合は「コンフィデンシャルクライアント」と呼ぶ。セキュアに保存できるケースとしては、サーバーサイドで保存できる場合である。それに対して、SPAによるフロントエンドでのみ行う場合や、ネイティブアプリケーションの場合は「パブリッククライアント」と呼ぶ。パブリッククライアントの場合、認証自体はOAuthで行わず、OpenID Connectなどの規格を用いて行うのが一般的。



## OAuthにおけるトークンについて

### アクセストークン
アクセストークンには、基本的には２つの情報が紐付いている
- 誰のどんなリソースに対してどんな事ができるのか
- 期限

OAuthのアクセストークンはBearerトークンなので、クライアントが誰なのか？については関知しない。
アクセストークンを所有している == その内容でできることは許可される
という扱いになる。

### スコープ
- 誰のどんなリソースに対してどんな事ができるのか
という部分の話。
スコープによって、どんなことができるかが分類される。
アクセストークンにどんなスコープが付けられるかは、クライアントから認可サーバーへのアクセス権リクエストの際に行われる。

ここのスコープは基本的には最小限にするべき。例えば必要ではないのにいきなり位置情報を要求してくるアプリなどがあるが、そういった場合はリソースオーナーは不審がって許可しないだろう。

### 有効期限
期限の話。
アクセストークンには期限があり、期限を過ぎたトークンでのリクエストは拒否される。
アクセストークンの有効期限は、後述するリフレッシュトークンの有効期限に比べて短くするのが通常。基本的にはexpire_inという項目に記載がある。

### リフレッシュトークン
リフレッシュトークンは、クライアントから認可サーバーにアクセストークンの再発行を要求するために使われます。
リフレッシュトークンは必須要件ではないが、大体の一般的に普及しているOAuthにはあると思う。

### 認可コード
認可コードは、リソースオーナーが同意した証として発行される。この証を用いて、アクセストークンを要求する。認可コードが利用できるのは一度だけ。また、流出の際の危険が大きいので、基本的には非常に短い時間で設定される。


## エンドポイントについて
OAuthのフローとして、最も代表的になグラントタイプである認可コードグラントでは、以下のエンドポイントが存在する。Googleログインとかをイメージすると理解しやすいかも。

### 認可エンドポイント
認可サーバーによって提供されるエンドポイント。役割は認可コードの発行。
クライアントが初回にアクセス権をリクエストした際には、この認可エンドポイントに認可コードの発行をリクエストします。
リソースオーナーはユーザー名とパスワードなどで認証を行い、特定の操作権限の移譲についての許諾を求められます。
同意により、認可コードが発行される。

### トークンエンドポイント
トークンエンドポイントは、認可サーバーによって提供されるエンドポイントのこと。認可コードを受け取ったクライアントは、認可コードと必要な情報を持ってトークンエンドポイントにリクエストを投げます。それによって、アクセストークンが発行されます。必要な情報というのはクライアントIDとクライアントシークレットなど。

### リダイレクトエンドポイント
リダイレクトエンドポイントはクライアントが用意するエンドポイント。リダイレクトエンドポイントは、認可サーバーから認可コード（他のグラントタイプではトークンの受け渡し。）を受け取るために行われる。認可サーバーは認可コード送信の同意が行われた段階で、302を返してリダイレクトエンドポイントにブラウザをリダイレクトさせます。その際に、クエリパラメータとして認可コードの値が渡されます。

###クライアントの登録について

トークンエンドポイントの話で少し出てきたが、クライアントの開発者はリソースを提供する組織（例で行くとGoogle)に対してクライアント情報を登録し、クライアントID,クライアントシークレットの発行を受ける必要がある。GoogleだとGoogle Developer Consoleでアプリを登録する。リダイレクトURIもここで登録したりする。



## グラントタイプについて
グラントは「付与」という意味。標準仕様では４つのグラントタイプが定義されている。それぞれに特徴があるのでケースによって使い分けると良い。ここでは認可コードグラントにフォーカスする。

### 認可コードグラント
一番大事だと思われる。

認可コードグラントはコンフィデンシャルクライアントに最適化されたグラント。現状ではPKCE(Proof Key for Code Exchange by OAuth Public Clients)を使用することで、パブリッククライアントでも推奨されるグラントタイプである。
リソースオーナー、クライアント、認可サーバの三者が登場し、４つのグラントタイプの中で最も複雑である。
3-legged OAuthという呼び方となる。

### シーケンス

1.認可コードの取得
クライアントアプリで、Googleから画像を取得を行う。「googleから画像を読み込む」みたいなボタンを押すイメージ。

2.クライアントはリダイレクトを行い、リソースオーナーを認可エンドポイントに誘導する。この時、認可エンドポイントにはリクエストに必要な情報がリクエストパラメーターに付与された状態。

具体的にはこんな風なリクエストが飛んでいる

```
GET リクエスト
/authorize
  ?response_type=code
  &client_id=hogehoge
  &state=fuga
  &scope=write
  &redirect_url=https%3A%2F%2Fcallback

```

#### response_type
値として、[code]が設定されている。認可サーバはここを見て、認可コードの発行を求められていることを判定しています。

#### client_id
クライアントの事前登録時に発行されたIDを入れています。ここで「どのクライアントか」を判断します。

#### state
クライアントが生成したランダムな値。stateをユーザーセッションと紐付けて管理することで、CSRFを防ぐ。

#### scope

クライアントの要求するスコープ。例ではwriteとして書き込み権限を要求している。

#### redirect_uri
クライアントの事前登録時に設定したリダイレクトURLが設定される。


3. 認可サーバーはリソースオーナーに本人認証を求める。email passwordでgoogleにログインする。（ここの認証方法はemail & passwordである必要はない）既にログインしている場合は、このフェーズはスキップされることもある。
4. ログインした後、認可サーバーはリクエストにあるscopeのリクエスト内容を評しする。「〇〇がxxに対して△△することを許可しますか？」のような画面が出る。ここで、リソースオーナーは同意か、拒否ができる。同意した場合は、認可サーバーから認可コードが発行される。
5. 認証した場合、認可サーバーがステータスコード302のレスポンスを返す。このレスポンスを、「認可レスポンス」と呼称する。このときのリダイレクトURLは2のリダイレクトURLになる。付与されるパラメータとして、codeとして認可コードの値、stateとして生成されたランダム値が付与される。
stateは最初のリクエストの際にランダム生成され、認可サーバーに渡されます。その後、認可サーバーから再度同じ値がクライアントに返される。クライアントはこの時、「最初のランダム生成の値」と「返ってきた値」が同一かどうかを確認する。これによって、CSRFを防ぐことができる。
6. 認可コードを受け取った後、認可コードを付与してクライアントからトークンエンドポイントに対してリクエストを投げる。これを「トークンリクエスト」と呼ぶ。トークンリクエストでクライアントの認証が行われる。

```
POST /token

Authorization: Basic hogehoge
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=hogefuga
&redirect_url=https%3A%2F%2Fcallback
```

ヘッダーにベーシック認証を行っているが、bodyにクライアントIDとシークレットを含めて渡してもいい。

#### grant_type 
認可コードグラントなので、authorization_codeとなる。

#### code
認可コードが入ってる

#### redirect_url
リダイレクトURL

### client_id, client_secret
事前登録の際に発行された値。この値で確認を行い、認可コードに紐付いたコードに対応したアクセストークンを生成する。

7.クライアントID,Secretの検証が問題なければアクセストークン、有効期限などが返ってくる。このレスポンスのことを「トークンレスポンス」と呼ぶ。
8.AuthorizationヘッダーにBearerという文字列とともにアクセストークンの値を設定し、リソースサーバーに対してリクエストを投げる。リソースサーバーは、リクエストが適切かどうかをチェックし、問題なければリソースがレスポンスとして返ってくる。

## インプリシットグラント
2019年に非推奨になったみたい。認可コードグラント + PKCEの組み合わせが推奨されている。

クライアントサイドがバックエンドと分離したSPAなどでは、アクセストークンがブラウザで見えてしまうので、情報漏えいのリスクが高くなる。

認可コードグラント+ PKCEの組み合わせによる認可コード横取り攻撃についてはまた次回。

