Now, here are some important and most basic authentication types-<\/p>\n
OAuth Authentication<\/strong><\/h2>\nOAuth is an open authentication protocol, which allows accessing the resources of the resource owner by enabling the client applications on HTTP services such as Facebook, GitHub, etc. It allows sharing of resources stored on one site to another site without using their credentials. It uses username and password tokens instead.<\/p>\n
Basically, there are three parties involved: oAuth Provider, OAuth Client,\u00a0and Owner.<\/p>\n
oAuth Client (Application Which wants to access your credential)
\noAuth Provider (eg. facebook, twitter…)
\nOwner (the person with facebook,twitter.. account )<\/p>\n
![\"OAuth](\"https:\/\/cdnblog.webkul.com\/blog\/wp-content\/uploads\/2019\/01\/Oauth-Authentication.png\")
FIg. OAuth type authentication<\/p><\/div>\n
Here is a diagram that depicts OAuth type authentication in a simple way-<\/p>\n
OAuth gives the Client the flexibility to choose which specific resources the client wants to use in its application.<\/p>\n
for example, if the Provider is Facebook, then the\u00a0client\u00a0can choose from the ‘messages’,\u00a0 ‘notifications’, ‘wall posts’ etc. to be used in its application.<\/p>\n
Digest Authentication<\/strong><\/h2>\nThis type of authentication is intended to replace unencrypted HTTP basic access authentication. It is not, however, intended to replace strong authentication protocols, such as public-key or Kerberos authentication.<\/p>\n
Digest authentication is a method of\u00a0authentication\u00a0in which a request from a potential user is received by a\u00a0network\u00a0server\u00a0and then sent to a\u00a0domain controller. The domain controller sends a special\u00a0key, called a digest session key<\/strong>, to the server that received the original request. The user must then produce a response, which is encrypted and transmitted to the server. If the user’s response is of the correct form, the server grants the user access to the network,\u00a0Web site\u00a0or requested resources for a single\u00a0session.<\/p>\nHowever, there is a disadvantage of this authentication,\u00a0digest access authentication provides no mechanism for clients to verify the server’s identity.<\/em><\/p>\nBasic Authentication<\/strong><\/h2>\nNext one in the list is Basic type authentication<\/strong>. In this, The server sends back a header stating that it requires\u00a0authentication<\/b>\u00a0for a given realm. The user provides the username and password, which the browser concatenates (username + “:” + password), and base64 encodes. This encoded string is then sent using\u00a0 “Authorization<\/strong>“-header on each request from the browser.<\/p>\nFollowing Image will help you understand the basic flow used in Basic type Authentication-<\/p>\n
![\"Basic-authentication\"](\"https:\/\/cdnblog.webkul.com\/blog\/wp-content\/uploads\/2019\/01\/basic-auth.gif\")
Fig. Basic-authentication<\/p><\/div>\n
It is relatively a simple protocol<\/em> and is supported by all the major browsers<\/em>. However, there are some drawbacks in using this type of authentication –<\/p>\n\n- User credentials are sent in the request.<\/em><\/li>\n
- Credentials are sent as plaintext.<\/em><\/li>\n
- Credentials are sent with every request.<\/em><\/li>\n
- No way to log out, except by ending the browser session.<\/em><\/li>\n
- Vulnerable to cross-site request forgery (CSRF); requires anti-CSRF measures.<\/em><\/li>\n<\/ul>\n
These drawbacks make\u00a0it a bit insecure as compared to the other types of Authentication.<\/p>\n
Token Based Authentication<\/h2>\n
Token-based authentication involves the issue of an access token<\/em> at the time of authentication. This token can be in different forms compatible with the ecosystem being used in. The client can enter their username and password in order to obtain an access token. The client keeps this token and sends it across with every request to the server. While processing every individual request from the client, the server doesn\u2019t know that the client is already authenticated – because HTTP is stateless – and so checks the token sent along and ascertains that the client is already authenticated and so provides access to the resources being requested.<\/p>\nFollowing fig will show the basic structure of a TOken Based Authentication-<\/p>\n
\noAuth Provider (eg. facebook, twitter…)
\nOwner (the person with facebook,twitter.. account )<\/p>\n
FIg. OAuth type authentication<\/p><\/div>\n
Here is a diagram that depicts OAuth type authentication in a simple way-<\/p>\n
OAuth gives the Client the flexibility to choose which specific resources the client wants to use in its application.<\/p>\n
for example, if the Provider is Facebook, then the\u00a0client\u00a0can choose from the ‘messages’,\u00a0 ‘notifications’, ‘wall posts’ etc. to be used in its application.<\/p>\n
Digest Authentication<\/strong><\/h2>\nThis type of authentication is intended to replace unencrypted HTTP basic access authentication. It is not, however, intended to replace strong authentication protocols, such as public-key or Kerberos authentication.<\/p>\n
Digest authentication is a method of\u00a0authentication\u00a0in which a request from a potential user is received by a\u00a0network\u00a0server\u00a0and then sent to a\u00a0domain controller. The domain controller sends a special\u00a0key, called a digest session key<\/strong>, to the server that received the original request. The user must then produce a response, which is encrypted and transmitted to the server. If the user’s response is of the correct form, the server grants the user access to the network,\u00a0Web site\u00a0or requested resources for a single\u00a0session.<\/p>\nHowever, there is a disadvantage of this authentication,\u00a0digest access authentication provides no mechanism for clients to verify the server’s identity.<\/em><\/p>\nBasic Authentication<\/strong><\/h2>\nNext one in the list is Basic type authentication<\/strong>. In this, The server sends back a header stating that it requires\u00a0authentication<\/b>\u00a0for a given realm. The user provides the username and password, which the browser concatenates (username + “:” + password), and base64 encodes. This encoded string is then sent using\u00a0 “Authorization<\/strong>“-header on each request from the browser.<\/p>\nFollowing Image will help you understand the basic flow used in Basic type Authentication-<\/p>\n
Fig. Basic-authentication<\/p><\/div>\n
It is relatively a simple protocol<\/em> and is supported by all the major browsers<\/em>. However, there are some drawbacks in using this type of authentication –<\/p>\n\n- User credentials are sent in the request.<\/em><\/li>\n
- Credentials are sent as plaintext.<\/em><\/li>\n
- Credentials are sent with every request.<\/em><\/li>\n
- No way to log out, except by ending the browser session.<\/em><\/li>\n
- Vulnerable to cross-site request forgery (CSRF); requires anti-CSRF measures.<\/em><\/li>\n<\/ul>\n
These drawbacks make\u00a0it a bit insecure as compared to the other types of Authentication.<\/p>\n
Token Based Authentication<\/h2>\n
Token-based authentication involves the issue of an access token<\/em> at the time of authentication. This token can be in different forms compatible with the ecosystem being used in. The client can enter their username and password in order to obtain an access token. The client keeps this token and sends it across with every request to the server. While processing every individual request from the client, the server doesn\u2019t know that the client is already authenticated – because HTTP is stateless – and so checks the token sent along and ascertains that the client is already authenticated and so provides access to the resources being requested.<\/p>\nFollowing fig will show the basic structure of a TOken Based Authentication-<\/p>\n
However, there is a disadvantage of this authentication,\u00a0digest access authentication provides no mechanism for clients to verify the server’s identity.<\/em><\/p>\n Next one in the list is Basic type authentication<\/strong>. In this, The server sends back a header stating that it requires\u00a0authentication<\/b>\u00a0for a given realm. The user provides the username and password, which the browser concatenates (username + “:” + password), and base64 encodes. This encoded string is then sent using\u00a0 “Authorization<\/strong>“-header on each request from the browser.<\/p>\n Following Image will help you understand the basic flow used in Basic type Authentication-<\/p>\n Fig. Basic-authentication<\/p><\/div>\n It is relatively a simple protocol<\/em> and is supported by all the major browsers<\/em>. However, there are some drawbacks in using this type of authentication –<\/p>\n These drawbacks make\u00a0it a bit insecure as compared to the other types of Authentication.<\/p>\n Token-based authentication involves the issue of an access token<\/em> at the time of authentication. This token can be in different forms compatible with the ecosystem being used in. The client can enter their username and password in order to obtain an access token. The client keeps this token and sends it across with every request to the server. While processing every individual request from the client, the server doesn\u2019t know that the client is already authenticated – because HTTP is stateless – and so checks the token sent along and ascertains that the client is already authenticated and so provides access to the resources being requested.<\/p>\n Following fig will show the basic structure of a TOken Based Authentication-<\/p>\nBasic Authentication<\/strong><\/h2>\n
\n
Token Based Authentication<\/h2>\n
![\"Token](\"https:\/\/cdnblog.webkul.com\/blog\/wp-content\/uploads\/2019\/01\/Token_based_authorization.png\")