REST APIの認証方法って何があるのだろう。
最近、REST APIを採用しようとしているけど、一般的な認証方式が知りたい
こういったお悩みを解決します。
■本記事の内容
本記事で以下の内容をお伝えします。
・Web APIの認証方式の種類
・REST APIでトークン認証を利用した実装例
■本記事の信頼性
この記事を書いている私は、プログラミングを仕事として始めて10年以上ほど経ちます。
今も現役のシステムエンジニアです。
初心者向けにREST APIの認証方法について解説していきます。
そもそもREST APIって何？って方は以下の記事で説明していますので読んでいただけますと幸いです。
サーバへアクセスをする場合は必ず何かしら認証を行っています。
皆さんもアプリなどを使われる際にユーザIDとパスワードを入力してログインしたりするかと思います。
もちろんですがはじめにログインできたからOKとはならず、ひとつひとつのアクセスに対してそのアクセスがちゃんとログインの認証プロセスを通ったものなのかを確認しています。
本記事はREST APIを最近知り始めた初心者向けに認証方法について説明していきます。
REST APIではトークン認証が一般的
結論から言いますとREST APIではトークン認証が一般的に使用されています。
RESTの考えからステートレスにしておくルールがあるため、サーバ側でセッション管理などを行う認証は行いません。
簡単にトークン認証について説明します。
サーバ側でアクセストークンという文字列を発行し、クライアントへ返すことにより、
クライアントはそのアクセスキーを用いてサーバへアクセスすることで、アクセスしてきたクライアントが正しいものかを判断します。
以下、よく使用されているトークン方式について説明していきます。
JWTトークンについて
トークン認証の中でもJWTトークンを利用することが多いです。
JWTトークンとはJSON Web Tokenの略称で、JSONデータを暗号化し署名を行ったトークンになります。
詳細はWikipediaを見て頂けたらいいかと思いますが、初心者向けに簡単に解説していきます。
JWTはBase64で暗号化されています。
その中の情報には、主に認証の情報とそのトークンの有効期限が記されています。
なおかつ、改ざん防止のため署名の情報も組み込まれています。
大きく３つのブロックに分かれていまして、以下のような形です。
クレーム部：認証情報や有効期限（システムによって変わる部分です）
署名部：上記のヘッダー部とクレーム部をハッシュ化したもの
これらの情報をサーバ側でJWTトークンをパース（分解）して、クライアントから送られてきたトークンは正しいものなのかを検証します。
BASE64なので簡単にデコードとエンコードができてしまいますが、仮に手動で有効期限を延ばしたり認証情報を変えたとしても署名のハッシュ値と差異が出るため不正なトークンであることが分かる仕組みです。
OAuthもトークン認証の一種
OAuthはご存知でしょうか？
ログイン画面にGoogleアカウントでログインするやFacebookでログインするみたいなボタンがよくあるかと思います。
あの代わりにログインするみたいな機能のことを指します。
本来であれば、認証・認可の処理は自身のアプリとして実装することが多いのですが、その認証・認可の処理を別の認可サーバーに任せてしまおうという方法です。
これらの認証にもトークン認証が利用されています。
WEB APIの認証方式
REST APIの認証方法としてはトークン認証が一般的と説明しました。
では、トークン認証以外にどういった認証方法があるか気になられている方もいるかもしれないのでご紹介したいと思います。
WEB APIでよくある認証方法は主に以下の3つが多いと思います。
その中でもほとんどがセッション認証とトークン認証が占めている印象です。
順に説明していきます。
Basic認証
一番簡易な認証方式です。
WEBサイトのコンテンツ取得にIDとパスワードの制限を設ける方法です。
ユーザごとにIDを管理しているわけではないので、IDとパスワードさえ知っていれば誰でもアクセスすることが可能です。
簡単に言うとシステム共通のIDとパスワードみたいなものですね。
家で例える家に入るための鍵になります。
人によってその鍵穴は変わるわけでもなく、その鍵穴に合う鍵さえ手に入れられれば誰でも中に入れるという仕組みです。
WEBアプリでは、このBasic認証が採用されることはないです。
あくまで簡易的な認証方式になります。
仮にBasic認証を利用するパターンがあるとするのであれば、だれが見ても同じ表示になる静的なWebページで仮に漏れても問題ないが、知らない人にアクセスさせたくないような時に利用することぐらいかなと思います。
特に個人情報を扱うシステムの場合は、Basic認証だけにするのはやめましょう。
セッション認証
続いてセッション認証です。
セッション認証とは、サーバとクライアント間でセッションという情報を保持し、その情報を用いて認証を行う仕組みです。
一度、ログインを行うとサーバ側でログインしたユーザの情報保持するようになります。
サーバ側からセッションIDと呼ばれるユーザを識別するためのIDを返却し、クライアントはその後のアクセスにそのセッションIDを使用して接続するといったイメージです。
このセッション情報は期限があり。ログイン後にある期間操作をせずに放置するとセッションタイムアウトになり、再度ログインする必要があります。
サーバレンダリング型のWEBシステムによくある認証方式です。
トークン認証
最後にトークン認証になります。先ほどトークン認証について説明しましたが、セッション認証と比べ何が異なるかを書いていきます。
まず、セッション認証との大きな違いは、サーバ側で情報を保持しないという点です。
先ほどのセッション認証ではログインしたユーザの状態を保持しています。
しかし、トークン認証はクライアントに対してアクセストークンを発行しますが、各ユーザの状態は保持しません。
サーバは、そのトークンが自身が発行したものかを確認し、許可もしくは拒否するイメージです。
このアクセストークンにも有効期限を指定することができ、その期限が切れていれば拒否する仕組みです。
感覚的にはセッション認証と少し似ていますが、セッション認証はサーバ側で状態保持するものでトークン認証はサーバ側で状態を保持しない（ステートレスと呼ばれます）認証だと思って頂ければいいです。
REST APIでトークン認証を利用した実装例
REST APIをトークン認証で行う実装例を簡単に書いていきます。
主にオンプレミスの場合とクラウドの場合で書いていきたいと思います。
オンプレミス
仮にJavaで実装した場合、フレームワークやライブラリを利用すれば比較的簡単に実装できます。
ただ、フレームワーク自体がサーバレンダリング型をメインしているものも多く、セッション認証であれば標準に機能として備わっているが、トークン認証を実装する場合は個別でコードを書く必要がでてきます。
例をあげますとJavaのフレームワークとして有名なSpringを利用する場合は自身でカスタマイズする必要があります。
トークンの発行処理もライブラリをインストールして利用する必要があります。
SpringだとUsernamePasswordAuthenticationFilterの認証フィルター処理を実装しているところがあります。
ここの部分はトークン認証の処理に書き換えてやる必要があります。
AWS
クラウドを利用した場合の実装例を書いていきます。
ここではクラウドのシェアNO1のAWSで書いていきたいと思います。
AWSではCoginitoと呼ばれる認証サービスがあります。
このCognitoがトークンの認証を実施してくれます。
こちらで特に何かを認証処理を実装する必要がありません。
後は、このCognitoで認証が通ったアクセスに対してどのサービスを認可させるかの設定を行うだけです。
簡単に例を出すとAPI GatewayやAppSyncなどです。
これらのサービスはAPIの入り口を管理しているサービスになります。オンプレでいうTomcatみたいな感じです。
やはりクラウドは一般的に必要になる技術はあらかじめサービス化されているため便利ですね。
最後に
WEB APIの認証にはトークン認証以外にセッション認証がある
セッションとトークン認証の違いはサーバ側で状態を保持するかしないか
AWSを利用すると標準でトークン認証ができてしまう
コメント