Additional scope-related items to consider while developing authorized apps
Depending on the type of grant used in the application, these scenarios must be considered:
For applications using OAuth2 SAML bearer grant
- The SAML assertion includes allowed API Gateway scopes for the
client based on the Infor Registry configuration for the client application type.
For example, the Infor Homepages application type has allowed the
Infor-homepages-allscope associated in the Infor Registry. So, SAML assertion issued to homepages includes theInfor-homepages-allscope. - If scopes associated with the access token do not match the scope required by the suite, API Gateway returns an HTTP 403 error to the client.
For applications using OAuth2 Authorization code grant
- When the client issues an authorization request, the client sends a list of
space-delimited scopes. For example:
- Request Infor-Mingle and Infor-IDM scopes
- Infor Ming.le mobile app requesting openid and Infor-Mingle scopes
- The authorization server will ask for consent from the user to access the API depending on the requested scopes and grants approval for those appropriate scopes.
- If scopes associated with the access token do not match the suite's scope, API Gateway returns an HTTP 403 error to the client.
For applications using OAuth2 implicit grant
- Associate required scope/s with the authorized app in Infor registry or the API Gateway user interface.
- Scopes associated with authorized apps are provided in the QR code/.ionapi file. The authorized app must support the new .ionapi file format.
- While making an authorization request, send the list of scopes corresponding to suites that the authorized app must access.
For backend applications using resource owner grant
- You can associate required scopes with the IFS Service Account configured for the backend service.
For headless applications using device authorization grant
- When the headless app initiates device authorization, it can optionally send scopes allowed for the app.