Authentication Methods
There are several common authentication protocols that APIs generally use. In most cases, you will implement at least one authentication method in your Anypoint DevKit connector. To help you decide which method to use, this document offers a brief description of each of the most popular methods.
Basic Authorization
In essence, this authentication method demands that a client prove authenticity by entering a username and password. For example, an application might be designed to accesses a user’s Facebook account and checks if any of the user’s friends "like" their own posts. In order for this to work, the application must be able to access private information from the user’s account, and can do so by demanding that the end user provide his or her username and password.
While this authentication method meets the need of the application, it also opens the door for the application to do much more than simply check for "self-liked" posts. With that in mind, this method may be unacceptable, as providing username and password credentials potentially enables nefarious activity.
OAuth
A broadly-used alternative to username-password authentication is OAuth (Open standard for Authorization). The OAuth protocol allows 3rd-party applications limited access to a resource through an alternative and restricted token. Using this, an application can access a user’s account, for example, without knowing the user’s actual login credentials, thus limiting the application to perfrom selected operations.
Unlike other protocols, OAuth retains a state (for example, connected) in a cookie and, therefore, doesn’t need to send token information with each request it submits. Commonly, APIs employ one of two versions of OAuth: OAuth 1.0a and Oauth 2.0; connecting to each of these is subtly different.
Access Implementing OAuth 1.0 Authentication or Implementing OAuth 2.0 Authentication for further details on how to connect to an API which uses OAuth.
Other Protocols
| Method | Description | Connectors | When to Use |
|---|---|---|---|
SAML |
When contacted by a known client, the service asks the Id Provider for passwords; the client never has access to them. |
Authenticating to server using federated identity. |
|
Kerberos |
The client authenticates itself directly to the Id Provider. The client is then given the password, but encoded under a key that only the Web service can crack. The client sends this encoded password to the Web service, which trusts that if it can crack it then the client is endorsed by the IdP. |
- |
Unsecured networks where network architecture allows server and client access to a key provider. |
NTLM |
The client sends a request; the NTLM server responds with a challenge message, and the client responds with the authentication message. Authentication is based on two hashed password values. NTLM is an old protocol which does not implement any of the more recent cryptographic methods. |
Authentication via NTLM is possible by configuring an NTLM proxy in the HTTP Endpoint. |
Clients that can’t use Kerberos, or networks where a domain controller is not available. |
LDAP |
Usernames and passwords are stored in a database on an LDAP server, not by the service provider. The exact authentication method varies. There are several methods available, including using certificates and encryption with Transport Layer Security (TLS). |
A private network accessible only from the server (as it allows credentials to be stored in a network inaccessible to the client). |
SAML
SAML (Security Assertion Markup Language) is an XML, open standard that allows third parties to offer an identity-providing service. In this modality, the user’s passwords lay in the Identity Provider’s (IdP) server. Whenever the user requests to log in to a Web service, the Web service turns to the IdP for the appropriate credentials. The benefits of this solution include minimizing security risks (phishing opportunities are reduced) as well as simplifying the log-in process for the user. In the Facebook example [Basic Authorization ] above, the application would not know the user’s password, as Facebook would be requesting it from a external IdP.
Kerberos
Kerberos is an open, complex protocol, developed by MIT and used by Active Directory among many others. Relative to SAML, it is a bit more challenging to set up properly, but it’s ideal for communication over non-secure networks as identity information travels encrypted in every stage. IdPs and Service Providers hardly interact with each other directly in this protocol; they send encrypted info to each other through the user. In the example above, the user’s password is unknown to the application; though it handles the password, it cannot un decrypt it.
NTLM
NTLM (NT LAN Manager) is a suite of security protocols designed by Microsoft for Windows networks. It uses three messages in a challenge-response structure, in which an NTLM server provides authentication. The client sends a request for negotiation advertising its capabilities; the NTLM server responds with a challenge message and the client responds with the authentication message. Authentication is based on two hashed password values: the NT hash and the LM hash.
NTLM is an old protocol which does not implement any of the more recent cryptographic methods; as such, it is no longer recommended by Microsoft. It is used for clients that cannot implement Kerberos, or for networks where a domain controller is not available. In Active Directory, NTLM has been replaced by Kerberos as the default authentication protocol.
LDAP
The Lightweight Directory Access Protocol (LDAP), is a public standard that facilitates distributed directory information, such as network user privilege information, over the Internet Protocol (IP). When using LDAP authentication, usernames and passwords are stored in a database on the LDAP server. The entity with which you wish to authenticate access (be it a server, application or Web service) queries the LDAP server, then grants or denies authentication based on the response. This makes it possible to avoid storing user names and passwords on the entity itself as they are stored in the LDAP server’s database.
Strictly speaking, authentication takes place between the entity to which you connected and the LDAP server. The exact authentication method varies according to the configuration of the entity and the LDAP server. There are several methods available, including using certificates and encryption with Transport Layer Security (TLS).
See Also
-
Read a basic introduction to OAuth on our MuleSoft Blog.
-
Read more about how OAuth works on our MuleSoft Blog.