client_id

demoapp

yes

The Client ID set when application was registered. Identifies which app is making the request.

scope

openid email profile offline_access visma_api:read

The “visma_api:read” scope-name above is just an example - check your API documentation for scope(s) to use.

yes

Identifies the user information that your application is requesting. One scope  openid is required. The values passed in this parameter inform the consent screen that is shown to the user.

Note: If your application is configured with Offline Access, you can include the  offline_access scope to get

redirect_uri

https://demoapp.example.com/oauthcallback

yes

Determines where the OAuth Callback response is sent back to your application. The value of this parameter must exactly match the value added on application registration. This includes the https scheme, the same case.

code_challenge

The code challenge generated

yes,  when PKCE enabled

Base64-URL-encoded string of SHA256 hash of the Code Verifier.

code_challenge_method

S256 or plain

yes,  when PKCE enabled

Whether the challenge is the SHA256 hash of the string or the plain verifier string.

response_type

"code" or "code id_token"

yes

Determines whether the OAuth 2.0 endpoint returns an authorization code and possibly an id_token. If  Hybrid Flow is enabled, the value must be set to "code id_token"

nonce

qksKW97hcv

yes, for Hybrid Flow

Nonce (Number Only used once). A string value which will be included in the response from Visma Connect, used to prevent token replay attacks. The value is passed through unmodified from the Authentication Request to the ID Token. If present in the ID Token, the application must verify that the nonce value is equal to the value of the nonce parameter sent in the Authentication Request. If the nonce value has already been received and used, the Application must not accept it. If  Hybrid Flow is enabled, a nonce value is required.

state

This field can be a Base64 encoded JSON object that can hold multiple values

no

Authorization protocols provide a state parameter. During authentication, the application sends this parameter in the authorization request, and the Authorization Server will return this parameter unchanged in the response. Your application can use this parameter in order to make sure that the response belongs to a request that was initiated by the same user. Therefore, state helps mitigate CSRF attacks. Restore the previous state of your application. Read more

response_mode

form_post or query

no

Specifies how response parameters are returned to the client, by posting a form or in a query string. Default and recommended way is form_post.

ui_locales

nb-NO sv-SE en-GB

no

End-User's preferred languages and scripts for the user interface, represented as a space-separated list of BCP47 [RFC5646] language tag values, ordered by preference. Values currently supported:

• Dansk  da-DK

• English (United Kingdom)  en-GB

• English (US)  en-US

• Suomi  fi-FI

• Norsk  nb-NO

• Nederlands  nl-NL

• Svenska  sv-SE

• Latviešu l v-LV

tenant_hint

604ad704-772a-46f7-8926-571769f067e7

no

Tenant ID (context) for Applications doing authorization of user-roles as part of Visma Connect.

grant_type

authorization_code

yes

As defined in the OAuth 2.0 specification, this field must contain a value of authorization_code.

redirect_uri

https://demoapp.example.com/oauthcallback

yes

The same value used on the authorization request.

code

94c99b73c13c1e39f7b0a7d259628338

yes

The authentication code returned from the initial request.

client_id

demoapp

yes

The Client ID set when application was registered. Identifies which app is making the request.

client_secret

The secret obtained when registering the application

yes

This is your application's Client Secret.

code_verifier

The generated verifier

yes, when PKCE enabled

The code verifier for the PKCE request, that the app originally generated before the authorization request.