K2 Five (5.2) supports inbound OAuth as in this means 'incoming' integration where third-party systems need to interact with K2 APIs. Examples include custom applications that need to start workflows, retrieve and complete workflow tasks, or execute SmartObject methods via K2 APIs. In this scenario, the bearer token is verified and used by K2 to authorize the incoming request. These incoming tokens are not cached by K2. This article describes how to set up and use inbound OAuth
I am not sure I understand which OAuth flow (aka grant type) this refers to - the authorization code grant type allows an end user's browser to redirect to the identity provider (e.g. Azure AD, Okta, etc.) to basically exchange the OAuth authorization code for an access token.
All the K2 documentation seems to assume a) Microsoft Azure Active Directory (AAD) identity provider and b) Smartforms instead of a custom UI
But the client credentials grant type allows for server-to-server integration to support, for instance, an custom ASP.NET app to make GET/POST requests to the K2 REST API on behalf of an authenticated user (specifically, authenticated to the ASP.NET app using either IIS Windows Authentication or Okta)
In this case (OAuth2 client credentials grant type), how can the ASP.NET server IIS start workflows, retrieve and complete workflow tasks, or execute SmartObject methods via K2 APIs? As far as I can tell, the REST API does not support a (secure, un-spoofable) mechanism in the GET (query string) or POST (request body) for the custom form/app server to indicate which user (human) is making the request.
Bottom line - Does this mean that K2 REST API does not support the OAuth2 client credentials grant type for use with custom forms built using a non-SmartForm technlogy e.g. PHP, .NET, React, etc.)?
Comments, ideas, appreciated.