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 *:
End user wants to use functionality powered by Telenor in your application
Your application redirects the user (or open a browser) to Telenor Norway using a client id (/oauth/v2/authorize?client_id=&state=)
End user is authenticated and gives consent so that your application can fetch the user's data
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)
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:
What it's used for
Where to find it
client_id_parameter is an OAuth parameter that identifies your client. Think of it as an application id.
Under your apps in your dashboard
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
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
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.
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
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.
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.
You can ignore the refresh_token and token_type response parameters in the doc. They are optional for now.