I am reading this Auth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens
The manual states that the client asks the auth server for an access token. However, the manual does not specify the way (HOW) that this happens. Is this happens during the mutual TLS procedure? or after that?
Related
The primary purpose of an authorization code in the oAuth flow is to prevent replay attacks, TLS also prevents replay attacks.
If you simply made a password grant request to an oAuth enabled server using TLS would that not be sufficient?
The primary purpose of an authorization code in the oAuth flow is to
prevent replay attacks
I think the primary purpose of Authorization Code flow is different then prevent replay attacks. OAuth does not guarantee this and regardless of the grant, OAuth 2.0 suggests us use always TLS for all grants to transmit Access token:
Access token credentials MUST only be transmitted using TLS as
described in Section 1.6 with server authentication as defined by
[RFC2818].
There are also other grants in OAuth 2.0 like;
Authorization Code
PKCE
Implicit (Legacy)
Client Credentials
Password (Legacy)
Device Code
Refresh Token
and each has its own purpose. Password flow is legacy and you should have a strong reason to keep using it because of the following reasons:
Your user exposing their credentials to 3rd party for no reason. It was the reason OAuth exist, not sharing credentials to 3rd party (like e.g: Service Foo) to get access to their service (like Google, Facebook)
User does not have any control what your Service Foo can do with these credentials.
It was required before like Implicit flow, but both Password and Implicit flows are replaced now with Device and PKCE based on their usage. For instance; if the main reason one application uses Password Grant is their clients can not support redirection, they can also use now Device Code Grant.
I am trying to understand how JWT authentication is stateless. In stateful authentication, there will be a session id. Here there is a JWT token which is signed. So the authentication server issues the JWT token, but can I say the validation of the JWT token in subsequent requests are done by the endpoint server (application server) rather than the authentication server. I believe this is possible as JWT is signed with expiry date (and also some other information) and the public certificate of authentication server is available to all endpoint servers.
So the authentication server will be only responsible for issuing the tokens and not validation. The validation will be done by the endpoint server.
Is my understanding correct? Is this how JWT is made stateless? Otherwise, I don't see how it is different from a stateful authentication as both can be implemented using tokens.
In stateful authentication, the centralized server will be responsible for issuing the tokens as well as validation is each request.
JSON Web Tokens (JWT) are referred to as stateless because the authorizing server needs to maintain no state; the token itself is all that is needed to verify a token bearer's authorization.
JWTs are signed using a digital signature algorithm (e.g. RSA) which cannot be forged. Because of this, anyone that trusts the signer's certificate can safely trust that the JWT is authentic. There's no need for a server to consult the token-issuing server to confirm its authenticity.
Notice in this diagram that the Resource Server does not need to check back with the Authorization Server:
Source: https://jwt.io/introduction/
In stateless authentication there is no need to store user information in the session. We can easily use the same token for fetching a secure resource from a domain other than the one we are logged in to.
Refer : https://www.jbspeakr.cc/purpose-jwt-stateless-authentication/
One of a vendor API documentation mentions that their API calls require to use HTTP Basic Authentication scheme, i.e. user:password Base64 encoded but, their token API (Login equivalent) documentation mentions that "..this service implements OAuth 2.0 - Resource Owner Password & Credential Grant"
Isn't HTTP Basic Authentication different from OAuth ?
Yes, HTTP Basic Authentication different from OAuth 2.0. However, the Resource Owner Password Credentials Grant utilizes Basic Authentication Scheme within the Authorization Request for the Client's credentials as described with section 4.3.1. Authorization Request and Response
The Resource Owner Password Credentials Grant is typically used to convert legacy systems to OAuth 2.0 and no more secure than Basic Authentication Scheme.
Resource Owner Password Credentials Grant is intended to be used when no other Grant Types are available and ONLY when there is a high degree of trust between the Resource Owner and the OAuth Client .
Yes, they both are different.
Http Basic : This is for authentication and user credentials are encoded then passed in HTTP header to the client server.
Basic example for HTTP Basic : Just like traditional web application which asked user to provide credentials and these credentials sent to server in HTTP header. Later server utilize those credentials to authenticate the user.
OAuth 2 : This is for authorization, here the client server required authorization of user data(resource owner) from authorization server.
Basic example for OAuth 2 : Let say there is a online game application running on a server, the user accessed the application which starts loading into user's browser. Now that application asking grants from user to post data about games on his Facebook account. Here user authorize his that application to access his Facebook posts through OAuth Standard. Refer the internal mechanism https://www.rfc-editor.org/rfc/rfc6749
Basic access authentication usage is comparable to OAuth 2.0 Client Credentials Grant Type.
A session can be created using Basic Authentication and services can be accessed using a sessionid in a stateful environment.
But if you do not want to use the session due to session limitations or stateless services, you can use the OAuth 2.0 Client Credentials Grant Type instead, which creates a token instead of session and sessionid. This token provides access to the services.
HTTP basic access authentication:
This is the simpler method for meeting the requirements to access a web service. It is simple because it doesn’t require any of the usual processes in a credentials system: cookies, session IDs or access pages. The whole HTTP basic authentication process is based on standard fields in the HTTP header. Thus, it avoids handshaking: the automated process by which two entities establish authenticated communication before starting normal communication via the established channel. This means equipment can communicate with an external device only if there is successful authentication; otherwise, the communication channel is not created. The connection via modem would fail, for example. The secure development of the basic HTTP access authentication method is HTTPs.
To prevent the basic HTTP access authentication method causing the browser to launch a username and password request for each access, the browser must store this information in the cache for a prudent length of time that doesn’t reduce security excessively. These security credentials are usually stored for 15 minutes.
What is this basic HTTP access authentication method like in the real world?
The access credential provided to third-party developers who want to connect to a mobile API is a totally secret alphanumerical ID.
This alphanumerical API key is stored in a secure space on the server.
The developer making requests for a particular service contained in this API should place this secret ID within the HTTP authorization header along with the word Basic. The two elements together allow the server to recognize the alphanumerical credential and provide access.
GET /private/index.php HTTP/1.1
Host: example.com
Authorization: Basic alphanumerical ID
OAuth 2.0:
OAuth represents a step forward in the use of credentials for authentication of API service users. It is a major advance on the basic HTTP access authentication method. Today it is practically the only security method that is almost 100% reliable, and its reliability is based on creating unique authentication tokens for each user. If this access token is compromised, it is deleted and a new one is issued. This means that the API’s own credentials are safeguarded.
The authentication process is as follows:
A user launches a native application and is asked to give a username or email address and a password to identify themselves as a user.
The type of request used to send this credential to the API is a POST request, which ensures private delivery of secret data. This request is sent via the SSL (Secure Sockets Layer) protocol, designed to enable applications to transmit outbound data securely. SSL facilitates giving and receiving encryption keys between applications.
This request allows to validate user credentials and to create ad hoc an authentication or access token that will expire after a time, or if the user or developer responsible for the API believes it to have been breached.
This authentication token is stored in the device to facilitate access to the API’s services that support the application itself.
If we compare both methods, OAuth 2.0 provides better security criteria because any initial request for credentials is made under the SSL protocol and because the guaranteed access object is a temporary token. In the basic HTTP access authentication process, access to API services always relies on sending credentials via the web, specifically in the HTTP header, which makes it much vulnerable to third parties.
Alright, I've spent several days looking for a proper solution on how to properly authenticate users when working with SPAs.
I have my own website.
I have my own API.
I have my own Single Page Application.
I have my own database of users.
The Goal: I need to get an access_token by providing a username and a password.
I looked at OAuth2 Implicit Grant, but it requires users to Approve/Decline the app after successful authentication. It doesn't work in my case since I own both the app and the API.
I looked at OAuth2 Password Grant, which is not perfect since I need to expose client_id/client_secret.
The reason I'm looking at OAuth2 is because the API will eventually be public.
Is there a standard way of doing this? My current options:
Forget about OAuth2 and manually generate access_token when user POSTs username/password (in this case I'd have to introduce OAuth2 when API goes public)
Use OAuth2 Password Grant and inject client_id/client_secret on the server, so just to keep client app very simple (also avoid all of those dev/staging/prod client_id/client_secret pairs)
Implicit Grant
You are right that Implicit grant type does not look appropriate. But I think your reason for not favoring it is incorrect because the approval step is not mandatory and in Spring OAuth 2 implementation (I don't know which implementation you are using) you can configure the Authorization server to auto approve authorization requests so that the approval step is skipped.
The reasons I think the "Implicit flow" is not suitable are
The client authentication step by providing client secret and authorization code is missing. So less security.
The access token is sent back as a URL fragment (so that the token doesn't go to the server) which will continue to stay in browser history
If XSS attack occurs, the malicious script can very well send the token to the remote server
Resource Owner Password Credentials Grant
If the authorization server and the resource server are the same, I think this is a quick way of getting up and running. RFC 6749 in Section 4.3.2 says:
If the client type is confidential or the client was issued client credentials (or assigned other authentication requirements), the client MUST authenticate with the authorization server as described in Section 3.2.1.
This means that the client authentication with client secret is not mandatory here. Now, for authorization code grant type, we need the client secret because the user provides his/her credentials directly to the authorization server and then when the client requests for the access token, it doesn;t have anything else other than the client secret to prove to the authorization server that this is a genuine request.
But in case of resource owner password credential grant type, the user has provided its credentials to the client itself and the client will then send these same user credentials for requesting access token. Therefore, the access-token request can be authenticated with the user credentials only and if we don't provide a client secret here, I don't think we are losing anything in terms of security.
So, you can definitely use password credential grant type in your SPA.
Authorization Code Grant
I think this should be the preferred option provided the client secret is not stored in the browser. After user authentication (and optionally user approval), the authorization server can redirect the browser to a server side endpoint with the authorization code in the URL. The server side end point will the request for the access token using the authorization code, client id and client secret (which is stored in the server side only). Once the access token is available, the server side endpoint can redirect (HTTP response code 302) the user to the SPA URL with appropriate cookies for CSRF protection and access token. Thus we are not storing the client secret in the browser.
By using authorization code grant type, you are basically making the solution more secured and generic. In future, if you want to do a single sign-on with a different SPA, you can do that easily by reusing the same authorization server with its integration with the authentication database (preferably an LDAP server).
For further details, refer to my StackOverflow answer here.
Building off what has been said already, I would recommend the 'Authorization Code Grant' but with the addition of the PKCE (Proof Key for Code Exchange / 'pixie') extension - for added security, regardless of whether you're implementing a 'public' or 'confidential' type client.
With PKCE, you don't need a client-secret for public clients (/it's kind of like generating a temporary client-secret at the very outset/beginning of each authentication attempt/instance - although even with PKCE for confidential clients you should ideally still use a client secret).
When reading about securing an app with JWTs, it is often said that the client initially gets a token from the server and then sends this token along with every request to the API.
This approach works great, once you have a token. As far as I can see, the default way of transferring a token is using an HTTP header, namely Authentication with Bearer as the prefix of the token as value.
But - is there also a default way of how to get the token initially? In samples you often see that this is just a simple request to and HTTP endpoint, that then returns JSON. But I was wondering whether there is something more of a standard workflow that e.g. describes what should be the name of this endpoint, as in OAuth2?
Any hints?
JWT is a token format which is used in security protocols like OAuth2 and OpenID Connect.
How to get the token from the authorization server depends on the grant flow you are using.
There are 4 grant flows defined in OAuth 2.0 that are intended for different clients and uses.
Authorization code grant
This grant is intended for web applications. The user's browser is redirected (HTTP 302) to the authorization server. The authorization server takes care of authenticating the user (via username/password, smartcard, 2-factor auth whatever).
The authorization server then redirect the browser back to a preregistered endpoint in the web application with a code. The web application then uses it's own credentials (client id and client secret) and the authorization code to request an access token from the authorization server.
The authorization server returns an access token and a refresh token to the web application. Note that the browser (untrusted) never sees the access token. Only the web application (trusted) has access to the access token and refresh token.
This grant is difficult to use from other clients than web applications as it's based on HTTP redirection.
Implicit grant
This grant is used for untrusted clients like JavaScript applications or 3rd party mobile clients (the ones you download from the app-store).
It also redirects a browser (or browser control) to the authorization server, but instead of returning a code to the browser after successful authentication, it returns an access token directly. Because the client is not trusted, the grant does not return a refresh token. The access token needs to be stored somewhere and is vulnerable to XSS attacks.
Even though you do not get a refresh token, some implementations do provide a way to get a new access token by communicating to the authorization server in a hidden IFRAME and using cookies to authenticate with the authorization server itself.
Resource Owner Password Credentials grant
This grant is for trusted clients, for example a desktop application or a first party mobile app with secure storage capabilities. The client application asks the user (the resource owner) for their username/password and then sends this to the authorization server to acquire an access token and refresh token.
Once the client has the access token, it can discard the password as it can use the refresh tokens to get new access tokens. This makes it more secure than basic authentication.
This grant does not depend on browser redirects and can be easily used from any application that can execute HTTP requests.
Client Credentials grant
This grant is meant to authenticate the client (application) instead of the user of the client.
In this case, the client submits its client id and secret directly to the authorization server to acquire an access and refresh token.
So basically the first two grants depend on browser-like capabilities (HTTP redirects, HTML login pages), where the other two grants only need an HTTP stack to communicate with the authorization server.
Every OAuth2 server has its own endpoints. The client can discover the name of relevant endpoints using discovery protocols like http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata.