「認可」の時、あまり意識しませんが、リフレッシュトークンも取得できる場合があります。
(Google の場合、「認可」要求時に「access_type=offline」を指定する)
実は、このことは結構重要な事なのですが、「認可」を行うユーザーの画面では気づき難いです。
アクセストークンの有効期間は60分ですが、リフレッシュトークンはより期間が長いです。
はっきり確認していませんが、デフォルトではユーザー本人が意識しないとずっと有効のままのようです。
もちろんユーザーが「認可」を取り消せば、無効になります。
リフレッシュトークンはアプリケーションで保管されると、極端に言えば、ユーザーの意思には関係なく
アプリケーションはいつでもユーザーの情報を取りに行く事が出来ます。
ですので、ユーザーがその事を知らないとセキュリティ上問題なのです。
上記を FORM 形式で POST することで、アクセストークンが JSON 文字列の一部として取得できます。
下に例を示します。
//
// リフレッシュトークンからアクセストークンの取得
//
String getAccessToken(
String url
, String client_id
, String client_secret
, String refresh_token
) {
String body = null;
String access_token = null;
ArrayList<NameValuePair> headers = new ArrayList<NameValuePair>();
ArrayList<NameValuePair> formparams = new ArrayList<NameValuePair>();
formparams.add( new BasicNameValuePair("client_id",client_id));
formparams.add( new BasicNameValuePair("client_secret",client_secret));
formparams.add( new BasicNameValuePair("refresh_token",refresh_token));
formparams.add( new BasicNameValuePair("grant_type","refresh_token"));
body = RestApi.doPostForm( url, headers, formparams );
if( body != null ) {
ObjectMapper mapper = new ObjectMapper();
JsonNode rootNode;
try {
rootNode = mapper.readTree(body);
JsonNode tokenNode = rootNode.get("access_token");
access_token = tokenNode.asText();
} catch (JsonProcessingException e) {
e.printStackTrace();
} catch (ParseException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}
}
return access_token;
}
RestApi.doPostForm() は独自に作成した class ですが、httpclient を FROM の POST で呼び出している単純なラッパーです。
JSON文字列は、Jackson で解析しています。
URL は認可の時アクセストークンを取得した先と同じです。
上記のコードは、JSP 中に埋め込めますが、動作を確認できたら、class 化して JSP の記述を
簡潔にしたほうが良いでしょう。
察しの良い読者ならお気づきと思いますが、
リフレッシュトークンはアプリ開発者には非常に便利な反面、ユーザーが意識しないと危険なものです。
例えば、Google Apps で組織で認証を行っているとします。
よく使われるのが、Google の認証画面でリダイレクトしてSAML を使って社内の ActiveDirectory(ADFS) で
認証させる方法です。
この場合、社外のネットワークからは社内のADFSサーバーにはアクセスできないので、認証できず、
Google アプリが使えません。
社外から一切 Google を使わせたくないと Google Apps管理者が考えているとすると、残念ですが十分ではありません。
その理由はあえて書かなくても解りますね。
| « 前頁 | 次頁 » |