getAuthorizationGrant
Request an authorization grant Allows clients to request an authorization grant to begin the OAuth2 flow. As an OAuth2 endpoint, all of the parameters and result variables from this endpoint have names that use underscores, versus the rest of the API which is camel-cased.
Clients must provide a username and password in the Authorization header of the request (or equivalent accessID, accessSecret and credentialType for SSO clients). This can be accomplished by setting a 'basic' authentication header using the user's username and password in compliance with Section 2 of RFC 2617 like shown below:
`Authorization: 'Basic base64(username:password)'`
Types of secrets
Sensibill supports 2 modes of operation for client secrets:
In the case where a client can guarantee a secret that is closely guarded, it allows for user administration support (e.g, deactivate, reactivate users, etc)
In the case where the secret may not be so secret ie. embedded in an application, the administrative actions are not allowed.
For an example, please refer to 'Authentication Step Five' of the jQuery Demo. Responses:
200: Success. The authorization grant was created successfully. Use the code in the body with the Access Token endpoint.
400: Bad Request. This will occur if you omit a required parameter, or if you provide an invalid value for a required parameter. It can also occur if you try to log in using a credentialType which your client is not authorized for.
401: Unauthorized. This will occur if the credentials you have provided are invalid.
Return
Parameters
This is the Client Key which you received when you created a developer account with Sensibill. It is a very long, random string encoded in base64.
This is the type of authorization grant being requested by the client. The only valid value here is \"code\", and must be sent by the client (it isn't filled in by default).
This is the URL which the user-agent should be redirected to if the login is successful. This is mostly only required by web-application clients which would like to access a Sensibill user's account, server-based clients which are handling authentication themselves (such as SSO) will likely ignore the redirect_uri and may even have to intercept the redirect in a user-agent. Note that while some clients may not need a redirection, all clients must provide a redirect uri in accordance with the OAuth2 standard. This is true even if you set `redirect=false` below. You must always have a redirect_uri, even if you don't use redirects. Always.
This represents the type of credentials that are being used to authenticate the user. The default is to authenticate a user using the email address and password that they provided to Sensibill when they registered. Some clients, referred to as SSO clients, will handle their own authentication. They can provide a credential_type to indicate what type of credentials they are using to authenticate a user. An example here might be \"abc_321_bank_internal\", indicating the credentials are stored internally by ABC321 Bank servers. Users may have multiple credentials stored, and thus can be identified in multiple ways by third party systems. (optional, default to "sensibill")
Can be either \"true\" or \"false\". Tells whether or not the authorizationGrant endpoint will issue a redirect if it successfully authenticates the user. Some clients which are unable to intercept a redirect might need to use this so that they can get the authorizationCode directly within the body. (optional, default to "true")