How to use OAuth to get authorization code with line authentication

For APIs that require end user consent and authorization the OAuth flow above is required*. This is to ensure that applications don't access user data without proper authorization and without end-user consent.

Line Authentication means the user is automatically identified using the mobile network or by using an USSD-flow instead of the end-user entering a username/password.

To get access to the API the user must authorize your application by following a standard OAuth process *:

  1. End user wants to use functionality powered by Telenor in your application

  2. Your application redirects the user (or open a browser) to Telenor Norway using a client id (/oauth/v2/authorize?client_id=&state=)

  3. End user is authenticated and gives consent so that your application can fetch the user's data

  4. Post a request to the OAuth-API (/oauth/v2/token) with the one time code returned in the callback (using client id and secret as basic authentication), to get an access token (time limited)

  5. Call Mobile User API to get data using the token *)

This figure, and the description, shows a best-case-situation. Several things might go wrong during the process. The most common will be that the end user doesn't give consent . This will also produce a callback to your application, but without an authorization code. Instead the following URL query parameters will hold information about the situation : error=access_denied & error_description=The resource owner denied the request. This error should be displayed to the end user in their browser in such a way that the user understands what happened, and what it means for the functionality in your application.

The parameters needed and where to get them is shown in the table below:

Name

What it's used for

Where to find it

Example values

client_id

client_id_parameter is an OAuth parameter that identifies your client. Think of it as an application id.

Under your apps in your dashboard

xhdrs6uleK1xyZBO

vX37PJ5wALcv1O9

client_secret

This is the secret for the client_id, which is an OAuth parameter that identifies your client. Think of it as an application password.

Under your apps in your dashboard

Glz2FV5XYOvAhFCE

state

This is a random number that you set in your own application to avoid cross site scripting. You can also use it as a message id to match a callback request to your original request.

You can set it to anything you want, but preferably not a fixed value

1234

Other

end user consent

In this OAuth flow, to get an access token the end user will have to provide their consent, You, as a developer, will not need to know how this is done. You can try with your own subscription or user, but you will never be able to change how the consent is given as this is controlled by Telenor.

N/A

N/A

Connectid username/password

These credentials are not involved in using the APIs at all. These are used by a developer to get access to the developer portal. This is a personal user that you can use for other Telenor services, like Min Sky.

If you need to register a new user, or if you've forgotten your password, you log in as a developer. If you need access to a specific company's apps, the administrator of that company must send you an invite to your connectid

username: myemailusername@example.com (or mobile number) Password: yourOwnChoice123

Min Bedrift Username/password

This user is not involved in the actual usage of the APIs. This is your single sign on user to the Min Bedrift Portal if your company has a Min Bedrift Agreement. You may have different roles within the company. If you are an API administrator, this is the user you should log in with to add developers.

If you need to register a new user, or if you've forgotten your password, you log in as a developer. If you need access to a specific company, a super administrator of that company must add you.

username: myemailusername Password: AbcD

In short:

Tip: It's highly recommended to use the state parameter to avoid cross site scripting. You can also use the state parameter as a message id to match the callback to your initial request.

Some pitfalls:

  • For now, the network authentication flow requires the site to use http. So you should have a simple http page to initiate the flow. All other pages must be https. The ussd flow works on either protocols

  • You must remember to configure the callback url for your app under “Applications” on the dashboard.

  • If you're going to use the APIs from Javascript on your page, you must configure the CORS headers for your app under “Applications” on the dashboard.

  • You can ignore the refresh_token and token_type response parameters in the doc. They are optional for now.