class oauthlib.oauth2.MobileApplicationClient(client_id, default_token_placement=u'auth_header', token_type=u'Bearer', access_token=None, refresh_token=None, mac_key=None, mac_algorithm=None, token=None, scope=None, state=None, redirect_url=None, state_generator=<function generate_token>, **kwargs)[source]

A public client utilizing the implicit code grant workflow.

A user-agent-based application is a public client in which the client code is downloaded from a web server and executes within a user-agent (e.g. web browser) on the device used by the resource owner. Protocol data and credentials are easily accessible (and often visible) to the resource owner. Since such applications reside within the user-agent, they can make seamless use of the user-agent capabilities when requesting authorization.

The implicit grant type is used to obtain access tokens (it does not support the issuance of refresh tokens) and is optimized for public clients known to operate a particular redirection URI. These clients are typically implemented in a browser using a scripting language such as JavaScript.

As a redirection-based flow, the client must be capable of interacting with the resource owner’s user-agent (typically a web browser) and capable of receiving incoming requests (via redirection) from the authorization server.

Unlike the authorization code grant type in which the client makes separate requests for authorization and access token, the client receives the access token as the result of the authorization request.

The implicit grant type does not include client authentication, and relies on the presence of the resource owner and the registration of the redirection URI. Because the access token is encoded into the redirection URI, it may be exposed to the resource owner and other applications residing on the same device.

parse_request_uri_response(uri, state=None, scope=None)[source]

Parse the response URI fragment.

If the resource owner grants the access request, the authorization server issues an access token and delivers it to the client by adding the following parameters to the fragment component of the redirection URI using the “application/x-www-form-urlencoded” format:

  • uri – The callback URI that resulted from the user being redirected back from the provider to you, the client.
  • state – The state provided in the authorization request.
  • scope – The scopes provided in the authorization request.

Dictionary of token parameters.


OAuth2Error if response is invalid.

A successful response should always contain

The access token issued by the authorization server. Often a random string.
The type of the token issued as described in Section 7.1. Commonly Bearer.
If you provided the state parameter in the authorization phase, then the provider is required to include that exact state value in the response.

While it is not mandated it is recommended that the provider include

The lifetime in seconds of the access token. For example, the value “3600” denotes that the access token will expire in one hour from the time the response was generated. If omitted, the authorization server SHOULD provide the expiration time via other means or document the default value.
Providers may supply this in all responses but are required to only if it has changed since the authorization request.

A few example responses can be seen below:

>>> response_uri = ''
>>> from oauthlib.oauth2 import MobileApplicationClient
>>> client = MobileApplicationClient('your_id')
>>> client.parse_request_uri_response(response_uri)
    'access_token': 'sdlfkj452',
    'token_type': 'Bearer',
    'state': 'ss345asyht',
    'scope': [u'hello', u'world']
>>> client.parse_request_uri_response(response_uri, state='other')
Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File "oauthlib/oauth2/rfc6749/", line 598, in parse_request_uri_response
    File "oauthlib/oauth2/rfc6749/", line 197, in parse_implicit_response
        raise ValueError("Mismatching or missing state in params.")
ValueError: Mismatching or missing state in params.
>>> def alert_scope_changed(message, old, new):
...     print(message, old, new)
>>> oauthlib.signals.scope_changed.connect(alert_scope_changed)
>>> client.parse_request_body_response(response_body, scope=['other'])
('Scope has changed from "other" to "hello world".', ['other'], ['hello', 'world'])
prepare_request_uri(uri, redirect_uri=None, scope=None, state=None, **kwargs)[source]

Prepare the implicit grant request URI.

The client constructs the request URI by adding the following parameters to the query component of the authorization endpoint URI using the “application/x-www-form-urlencoded” format, per Appendix B:

  • redirect_uri – OPTIONAL. The redirect URI must be an absolute URI and it should have been registerd with the OAuth provider prior to use. As described in Section 3.1.2.
  • scope – OPTIONAL. The scope of the access request as described by Section 3.3`_. These may be any string but are commonly URIs or various categories such as videos or documents.
  • state – RECOMMENDED. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. The parameter SHOULD be used for preventing cross-site request forgery as described in Section 10.12.
  • kwargs – Extra arguments to include in the request URI.

In addition to supplied parameters, OAuthLib will append the client_id that was provided in the constructor as well as the mandatory response_type argument, set to token:

>>> from oauthlib.oauth2 import MobileApplicationClient
>>> client = MobileApplicationClient('your_id')
>>> client.prepare_request_uri('')
>>> client.prepare_request_uri('', redirect_uri='https://a.b/callback')
>>> client.prepare_request_uri('', scope=['profile', 'pictures'])
>>> client.prepare_request_uri('', foo='bar')