">mixi Developer Center (mDC)

mixi Connect

mixi Connect (English) » mixi Graph API » Authorization and Authentication Process (Old Spec)

Authorization and Authentication Process (Old Spec)

In order to utilize various APIs from a client program, you have to implement appropriate authorization process in compliance with OAuth 2.0 Protocol. Following the process, a user is able to see what kind of information to be referred and/or renewal by what kind of API implemented within the program (we call it "Scope"). Only upon a user's consent to the scope and authorization, the client program can obtain the information (such as Token) to access to the API.

[The OAuth 2.0 Protocol draft-ietf-oauth-v2-10]


Prior to the authorization and authentication process, you have to obtain the following information:

  • Consumer key
  • Consumer secret

Please, see the Credential Information when registering the services.

Authorization and Authorization Code

At the beginning, a client program accesses to the following URLs via a web browser.

  • https://mixi.jp/connect_authorize.pl : (For PC and Smartphone)
  • http://m.mixi.jp/connect_authorize.pl : (For mobile phone, excluding the smart phone)

The following query parameters have to be specified for the access:

parameter value
client_id Consumer key
response_type "code"
scope Scope for the authorization
display Device which shows authorization/authentication window
state This value is included into a query parameter at redirecting after a user’s authorization.
If the application uses a session, this parameter should be used to verify its authenticity.

The value of the scope parameter is specified as a string list of scopes developers want to authorize divided by a white space. Please see each pages to know available scope values.

For display parameter, you can specify a device that the authorization/authentication window to be shown.

Available value Description
"pc" Window for PC desktop is shown
"touch" or
Window for Smart Phone is shown
"ios" This parameter is used for iOS to pass the review process by Apple.

If a device is a mobile phone (so-called Keitai), the display parameter is ignored and a window for the mobile phone is displayed. If the mobile device is a Docomo feature-phone, “guid=ON” should be appended to the URL as a query parameter.

If the session isn't verified using the state parameter, the application is vulnerable to CSRF attacks. To prevent this, place a hash (etc.) of the session ID in the state parameter, and after the authorization redirect verify that the session and state parameters match. See the link below for details.

You can specify all parameters with URL encoded text strings. Thus, overall URL is as follows:

GET https://mixi.jp/connect_authorize.pl?client_id=908ed4da74f885a2ab&response_type=code&scope=r_profile%20r_voice&state=5c1b3eea390b53f54ad0975e9a4bbba2

With appropriate value for each parameter, authorization/authentication window should be displayed. In the case, however, a user has logged in either "http://mixi.jp/" or https://mixi.jp/ the window is not shown. Besides, if a user has not set up "easy login" for a feature phone, a message comes up to prompt the user to set up the easy login.

The authorization window shows the list of scopes specified for scope parameter and a user is able to decide if the user consents to authorize the process for the client program.

Upon the user's consent, the access is redirected to the URL which specified for Redirect URL in registering the services, and a code parameter is added on the access as query parameter. Also, the state parameter is included as a query parameter, if you specify the state parameter at calling the page to authorize. Value of the code parameter is Authorization Code issued by mixi Platform.

Redirecting URL becomes as follows:


This Authorization Code shall expire in 3 minutes.

How to get Refresh Token and Access Token

The client program is able to get a refresh token and access token by using the Authorization Code. The program should access at "https://secure.mixi-platform.com/2/token" by POST method and the following parameters should be specified in a request body with application/x-www-form-urlencoded format.

Parameter Value
grant_type "authorization_code"
client_id Consumer key
client_secret Consumer secret
code Authorization Code
redirect_uri Redirect URI (must specify the URI inputted at registering the service.)

Whole URL and the request body looks like following:

POST https://secure.mixi-platform.com/2/token

If each parameter is appropriate, response should be as follows: such response is formatted as application/json

{"refresh_token":"39c5662a2e8b87d41c1eebe79f68af","expires_in":900,"access_token":"c2be2257f3dae3df4efcb010ae6eea","scope":"r_profile r_voice"}

Each value describes:

Value Description
refresh_token Refresh token text string to refresh an access token
expires_in Time when an access token to be expired in second
access_token Access token text string
scope Authorization scope list, concatenated with space

The access token is expired in 15 minutes. The refresh token may be expired based on a user's authorization.

  • If the user selects "always accept", the refresh token is expired in 3 months since last access to the API.
  • If the user doesn't select "always accept", the refresh token is expired in 6 hours.

Life of the access token and/or refresh token is subject to change without prior notice. You should not design any services based on the current expiring period or write hard coding the period on the client program.

When a request parameter is invalid, the response will have one of the following error messages. The format is application/json.

Error message Description
{"error":"invalid_grant"} "code", "redirect_uri", or both are invalid.
{"error":"invalid_client"} "client_id", "client_secret" or both are invalid.
{"error":"unsupported_grant_type"} "grant_type" is invalid.

Access to API

The access token enables you to access to various APIs specified as scope in the authorization process. URI for each API is different, while the access token can be used in common. In calling various APIs, the access token should be specified in the Authorization request header.

After "OAuth" and one space, the access token is stated.

For example,

GET /resource HTTP/1.1
Host: api.mixi-platform.com
Authorization: OAuth c2be2257f3dae3df4efcb010ae6eea

In the case, the Authorization request header is not available, the access token can be specified for oauth_token parameter.

For People AP, that code should be as follows:


Normally specifying the access token in the Authorization request header is preferable.

Error Message

When the access token is invalid due to the following reasons in accessing to APIs, such call to API fails and error message is sent as a response.

  • The access token has been expired, or:
  • A user doesn't authorize the sufficient scope

In this cases, "WWW-Authenticate" header which shows the error cause is included in the http response header.

HTTP/1.1 401 Authorization Required
WWW-Authenticate: OAuth error='expired_token'

Followings are the value for error parameter:

invalid_request Request is invalid
invalid_token The access token is invalid
expired_token The access token is expired
insufficient_scope A user doesn't authorize the sufficient scope for the access

If the access token is expired, the access token can be re-issued by following the procedure described below. If the access token is invalid, you should redo from Authorization and Authorization Code process.

How to re-issue the access token

The access token is expired only within 15 minutes, and thus accesses to each API would fail if the access token is expired. A client program can gain a new access token by using a refresh token. Refresh token is the value of the refresh_token that is included in issuing the access token.

In order to re-issue the access token, the client program accesses to https://secure.mixi-platform.com/2/token with POST method. In that case, the following parameters have to be described in the request body with application/x-www-form-urlencoded format.

Parameter Value
grant_type "refresh_token"
client_id Consumer key
client_secret Consumer Secret
refresh_token Refresh token text strings

Whole URL and request body should be as follows:

POST https://secure.mixi-platform.com/2/token

If each parameter is appropriate, you can get the following result: 。


Expiring refresh token

Based on the user's authorization and status of accessing APIs, a refresh token is expired. If the refresh token is expired, the following response is sent to you.

HTTP/1.1 401 Authorization Required
Content-Type: application/json

Expired refresh token would never work. You have to go through Authorization and Authorization Code.