Scopes For 3-Legged OAuth, 2-Legged 
OAuth, and OpenID Connect
In the flows described in this previous sections, we didn't go into too much detail about scope. The goal here is to talk about scope with reference to the prevoius flows.

How Scope Is Implemented

A scope is essentially rights that the resource owner has granted to the client. The client can then be permissioned to act on behalf of the resource owner when making an API call to the resource server. For example, a client may make an API call to gain read access to a resource owner's contact information by providing a 'read' value for the scope.  With regards to the specs, it's up to the authorization server to have predefine the scopes.  


Scopes Defined In The Covisint Platform

When integrating with or developing with other applications, such as Facebook, with 3-Legged OAuth, typically there are predefined scopes specific to that application.  On the Covisint Platform, only the 5 OpenID Connect scopes and the scope for SPA content are predefined:


Scopes For OIDC: 

  • openid – REQUIRED. Informs the Authorization Server that the Client is making an OpenID Connect request. If the oidc scope value is not present, the request MUST NOT be treated as an OpenID Connect request. The openid value also requests that the ID Token associated with the authentication session be returned. If the response_type includes a token, the ID Token is returned in the Authorization Response along with the Access Token. If the response_type includes code, the ID Token is returned as part of the Token Endpoint response. This scope value requests access to the user_id Claim at the UserInfo Endpoint.
  • profile – OPTIONAL. This requests that access to the End-User’s profile Claims excluding the address and email Claims at the UserInfo Endpoint be granted by the issued Access Token.
  • email – OPTIONAL. This requests that access to the email and verified Claims at the UserInfo Endpoint be granted by the issued Access Token.
  • address – OPTIONAL. This requests that access to address Claim at the UserInfo Endpoint be granted by the issued Access Token.
  • phone – OPTIONAL. This requests that access to the phone_number Claim at the UserInfo Endpoint be granted by the issued Access Token.
  • contentupload – (Required This scope must be used when accessing the UI proxy services to upload content and configure external proxies. Check out this [post](#) about UI proxy server). 

The first 5 scopes are just the default scopes for OIDC.  The contentupload scope is not predefined for the default ClientID/Secret in a solution.  In order to upload SPA content for an app hosted on the platform, a second ClientID/Secret must be created and the contentupload scope must be defined for that ClientID and Secret.


You Defined The Scopes For Your Application

Unlike other applications, like Facebook, that have predefined scopes with corresponding functionality, The Covisint Platform does not include default scopes.  Rather, if a solution includes 3-legged OAuth or OIDC in the functionality, scopes would be defined for that specific solution.  In other words, it's up to you to define the scope for your solution.  Again, if you are using OIDC, one of your scopes must be openid as defined by the OIDC protocol.  You are able to chain multiple scopes that are separated by spaces. 

Those scopes would have no specific functionality once instantiated on the platform.  Through the development of the solution and the integration of third party services, those scopes would be given context.

For example, if an OEM builds a connected vehicle solution on the Covisint Platform, the OEM might define a set of scopes that allow vehicle drivers to share certain information with apps developed within a partner ecosystem.  Such scopes might include:

  • Profile
  • Email
  • Device
  • Payment Info
  • Preference
  • Location

On the Covisint Platform, the scopes beyond the OIDC standard don’t have any meaning or functionality, but the app that is built on the platform would have additional services built in either based on information streamed from the vehicle or from back-end systems.  Authorization to access to the information related to those services would then be managed with those scopes.

Where the scopes come into play is when a third-party client application, such as a gas station partner,  is integrated into your application. The gas station application would be integrated using the 3-legged OAuth flows.  

The gas station client app might want access to the following scopes:

  • Device – Access to the ID of the vehicle
  • Location – Access to the location of the vehicle to know if it enters the geofence around a gas station location
  • Payment Info – Access to a digital wallet so that the driver could select a pump and pay for gas through an app on the head unit (pull up in front of pump 14, press a button to authorize the pump and pay)
  • Email – Access to the driver’s email to send a receipt

The scopes are defined on the OEM app on the Covisint Platform.  The partner app is integrated with OAuth or OIDC including the OAuth flows.  When the driver accesses the gas station app for the first time, the driver is prompted with a consent form.  The consent form is a standard part of the OAuth flow where the user is prompted to authorize the gas station app to access the information related to the scopes.

Once the user executes the consent form, allowing the gas station app to access the driver’s information within the scopes, the gas station app is programmatically allowed to access that driver’s information directly, without requiring any ongoing action by the driver.

In the background, the gas station app was given a refresh token and a bearer token, both with the scopes embedded in the tokens.  The gas station app can then use those tokens as described above to access the driver’s information via the Covisint APIs.

The gas station app is then able to access the location of the vehicle when it enters a geofence location of a gas station, then make it faster and more secure for the drivers to purchase gas – faster because the user isn’t wasting time swiping credit cards and more secure because the risk of credit card scimming is removed.