For those of you who need a refresher or maybe you are new and having trouble with understand Authentication in K2, I have put together a quick reference for the different authentication modes available when creating a service instance. I have also left some documentation at the bottom for further, more detailed reading.

Service Account

This option uses the K2 Blackpearl service account that was set up when K2 was installed. This is the easiest approach for granting authentication but, this ease of access comes at the cost of security. If the Service Account has the correct credentials that enable it to access this provider, it will automatically be able to access the provider and there is no restriction on who can have access to the provider. This mode is useful for accessing public data that does not need to be secured and the provider does not have high security requirements.

Impersonate

Impersonate is based around which user is currently attempting to access the provider. Impersonate will pass the current user's username and password onto the provider and attempt to authenticate the user. This is useful to ensure that only certain users have access to certain data or methods from the provider.  

SSO

SSO is used when the current user's credential type is not accepted by the provider. Most often this is used if the provider does not accept some sort of Active Directory authentication mechanism. Users can set up an alternate set of credentials in the K2 Workspace and whenever the provider is being accessed, be it through executing a method perhaps, these credentials will be used instead if SSO is selected. The credentials are cached  and encrypted when entered into the SSO store. K2 will generate a security token from the stored SSO credentials and pass that token onto the provider to grant the user access if their credentials are in fact valid.

Static

This method uses a specific username and password that is entered when creating the service instance. This is useful under the condition that the provider is using their own specific authentication mechanism. Another reason could be that there is one specific account that is not an AD account that you would like to use to access this provider. Be careful because this mode also has a high risk for security. Every time this service instance is used in a static mode, it will use the credentials specified. This is similar to the service account security risk because if this account has the correct credentials it will always allow access no matter who is attempting to access the provider.

OAuth

OAuth is an authentication mode used mainly for connecting to other LOB systems such as SalesForce.com, SharePoint, Twitter, and LinkedIn. Before using OAuth you must have configured the OAuth resource first and then identify it when setting up the service instance. OAuth is beginning to be used more and more as it is becoming implemented in more systems and becoming a standard. OAuth can also be used for authentication on any custom broker that you write because it is built into K2. For more information on OAuth and its configuration check out the KB: How to Configure OAuth in K2

Resources: 

For more in depth and detailed information on authentication check out the KB: Authentication and Authorization in K2

Or read over the Documentation for Service Broker Authentication here: Service Broker Authentication

White Paper on K2 Pass-Through Authentication(Kerberos Related): K2 Pass-Through Authentication Whitepaper