ログイン

ユーザーの作成が完了すると、登録した情報によるログインができるようになります。

また、REST API におけるログインを行うと、Kii Cloud はアクセストークンを返します。以後、ユーザーログインを必要とする REST API を利用する際には、このアクセストークンを HTTP ヘッダに埋め込むことになります。アクセストークンについては ログインとアクセストークン をご覧ください。

ログイン

ログインを行い、アクセストークンを取得する例を以下に挙げます。

curl -v -X POST \
  -H "Authorization: Basic {BASE64_ENCODED_APPID_AND_APPKEY}" \
  -H "Content-Type: application/json" \
  "https://api-jp.kii.com/api/apps/{APP_ID}/oauth2/token" \
  -d '{
        "grant_type": "password",
        "username": "user_123456",
        "password": "123ABC"
      }'

ログインは Basic 認証 を使って行います。{BASE64_ENCODED_APPID_AND_APPKEY} には AppID と AppKey をコロン(:)で連結した文字列を Base64 エンコードしたものを入れてください。

ここで、"username" に指定可能な値は以下のとおりです。

  • ユーザー名
  • 国際電話番号
  • メールアドレス
  • EMAIL:メールアドレス
  • PHONE:国際電話番号(例:PHONE:+819012341234)
  • PHONE:2 文字の国コード-国内電話番号(例:PHONE:JP-9012341234)

さらに "expiresAt" パラメータを指定することでアクセストークンの有効期限(UNIX 時間・ミリ秒、UTC)が設定可能です。有効期限の設定がない場合は、アクセストークンは永久的に有効となります。

ログインが成功すると、Kii Cloud は次のようなレスポンスを返します。このレスポンスにおける "access_token" の値がアクセストークンです。また "expired_in" は、アクセストークンが有効な時間(秒)となります。

< HTTP/1.1 200 OK
< Server: Apache-Coyote/1.1
< Content-Type: application/json
< Transfer-Encoding: chunked
< Date: Mon, 14 May 2012 22:52:52 GMT
<
{
  "id" : {USER_ID},
  "access_token" : {ACCESS_TOKEN},
  "expires_in" : 2147483647,
  "token_type" : "bearer"
}

リクエストの "expiresAt" とレスポンスの "expired_in" は表現形式が異なる点にご注意ください。"expiresAt" は日付での指定ですが、"expired_in" は現在時刻からの残り秒数です。たとえば、2015 年 12 月 1 日の正午(UTC)に翌日の正午までのトークンを取得するとき、"expiresAt" : 1449057600000 の指定により、"expires_in" : 86400 前後の値(24 時間× 60 分× 60 秒前後)が返ります。

取得したアクセストークンを保存する場合は、安全な方法や場所を選択してください。アクセストークンがあれば、ログインしたユーザーの権限で Kii Cloud の領域にアクセスできるため、機密情報として扱う必要があります。

ユーザーのパスワードが変更されると、アクセストークンは無効になります。この場合は、ユーザー名とパスワードを使ってログインを行い、新しいアクセストークンを取得してください。
また、ユーザーが無効化された場合も、アクセストークンは無効になります。

ログイン完了後、ログアウトする方法はありません。アプリの実装では、発行されたアクセストークンをクライアントのメモリ上から破棄することでログアウト相当とします(クライアント SDK も同様の実装です)。なお、一旦、ユーザーの 無効化 を行うと、発行済みのアクセストークンを無効にできますが、そのユーザーに紐付いているすべてのアクセストークンが無効になるため、注意が必要です。

ログイン失敗の原因

ユーザーが未登録の場合や、パスワードが一致しない場合は HTTP ステータス 400 が返ります。管理者によってユーザーが 無効化 されていた場合も HTTP ステータス 400 が返ります。

セキュリティ上の理由により、REST API ではこれらのどれが原因で失敗したのかを判別できません。ただし、管理者は 開発者ログ を確認することで、エラーの原因を特定することができます。