I have a login page, I get the user email and user password from the inputs.
I created a "fetch" in my JavaScript file, and sent the user email and user password to my backend.
Since there is indeed this email and password registered in my database, the backend returns my token inside a json.
This is my token:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJsb2NhbGhvc3QiLCJuYW1lIjoiVmluaWNpdXMiLCJlbWFpbCI6InZpbmljaXVzQGhvdG1haWwuY29tIn0=.YvasYRuuoreFzD5vzYJA5D33eDAyqcCDRWLu3ObRxkw=
I have my way to save it, I saved in the localStorage.
Now the user wants to use all the pages of the website, so I need to validate.
To do so, in the pages that need login, I created a new Fetch and passed the token in the header, like that:
header: {
'Content-Type':'application/json',
'Accept': 'application/json',
'Authorization': 'Bearer '+localStorage.getItem("token")
}
Everything alright so far. However, I don't know what to do when the data gets to my backend. Can you please confirm if my guess is right?
-> My token hits the backend, so I do the "reverse", that is, I decode the token to get the user email and password
-> I check if the email and password matches those of my database
-> I also create a new "jwt signature" with the email and password to see if it matches with the token's signature. I have to do this way because signatures have hash and hash can't be undone.
-> After working, I return a json saying to my front-end that she/he is allowed and If I want to, I return some data of the user to use in my page too.
Is that right? If not, can you please explain to me in a simple way? I have some issues to learn, that's why I couldn't understand much when I read some texts about it.
Please read more about it here https://jwt.io/introduction.
Basically, the token is base64-encoded so you can easily decode to read the content. Therefore it shouldn't include the credentials but only the id to identify the user (and extra data if needed). Then you can validate it using your secret key, it's depending on the algorithm you chose when issuing the token as well - here is HS256.
The last part of the token after dot (.) is the signature you need to validate. If it is correct then you know the token is valid and the current user from what you see inside the token.
For example if you want to use the HMAC SHA256 algorithm, the signature will be created in the following way:
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
Use the library that you use to issue the token to validate this, best to read its documentation.
For example, this is the content I decoded from your token:
{
"iss": "localhost",
"name": "Vinicius",
"email": "vinicius#hotmail.com"
}
So if you validated the signature you can believe that the user who is using this token is vinicius#hotmail.com
I few days ago I configured my AzureAd to get Id_Tokens for my app also with groupIds claims within the token.
Everything works fine, but if I add more than 5 groups to an user it fails because azure add the "hasgroups": "true" claims because token is to big to add it in the URL so I have to perform another request.
The point is that I am not be able to perform the request to then obtaining the groups. The token ID_TOKEN I have received is the following:
for the backend and front end azureAD filter this token is perfect and works fine
Then as it it said in the official Microsoft azure docs I have to perform another request to https://graph.microsoft.com/v1.0/users/{userID}/getMemberObjects
As you can see the aud claim is the same as my app client ID:
I am trying to perform the request with postman because I need it and this is the result
{
"error": {
"code": "InvalidAuthenticationToken",
"message": "Access token validation failure. Invalid audience.",
"innerError": {
"date": "2020-07-08T13:56:50",
"request-id": "6b2f3374-33e4-4a1a-9709-b8111cd2bc66"
}
}
}
As you can see the aud is not invalid because is the same as client_id
What am I doing wrong>? I have spent a lot of time dealing with that and I can't find the solution.
I have also tried with POST request and BODY
UPDATE
I found the problem, the problem was that I was using an id_token instead of a access_token. But for me ot would be ususer to be able to extract such information only by using id_token.
I still have a horrible inconvenience, because if you can only use access token I will have to change half the application because is only the front end which have access token and in backend I have aspects that were using id_token with the group information contained and did not need the access token at all .Now front end should have to add access token in every request header to be captured in backend to run son filters and aspects that are executed and require such information
Is it possible to get the same info but with id_token instead?
Instead of Get request use Post request for below query
Post https://graph.microsoft.com/v1.0/users/{userID}/getMemberObjects
{
"securityEnabledOnly": true
}
Please refer to this document
If you want to try with Graph explorer here is the link
The problem i am facing is that clicking on F12 on Chrome Browser , i could see all the Rest Calls which are made to fetch the data
For example , one of the REST API call is
(When clicked on the above link , it fetches the data )
This is my front code consists of Jquery
function displaymarketupdates() {
var updatedon = "";
var html = '';
var t = "",
$.ajax({
type: "GET",
url: e,
crossDomain: !0,
dataType: "json",
timeout: 17e3,
async: !0,
cacheResults: !1,
cache: !1,
contentType: "application/json",
charset: "utf-8",
beforeSend: function() {
$(".loadingWrapformarketupdates").show()
},
complete: function() {
$(".loadingWrapformarketupdates").hide()
},
success: function(response) {
},
error: function(t, e, a) {
$(".loadingWrapformarketupdates").hide()
}
}).done(function() {
})
}
And this is my service
#Path("/fetchallvalues")
public class FetchAllValues {
public FetchAllValues() {}
private final static Logger logger = Logger.getLogger(FetchAllValues.class);
#GET#Produces("text/plain")
public Response Fetch_all_values() {
PreparedStatement fetch_all_pstmt = null;
ResultSet fetch_all_Rset = null;
Connection dbConnection = null;
ResponseBuilder builder = Response.status(Status.NOT_FOUND);
final JSONArray fetch_array = new JSONArray();
final String inputsql = "select * from all_values";
try {
dbConnection = DBConnection.getDBConnection();
fetch_all_pstmt = dbConnection.prepareStatement(inputsql);
fetch_all_Rset = fetch_all_pstmt.executeQuery();
while (fetch_all_Rset.next()) {
====
}
Response.status(Status.OK);
builder = Response.ok(fetch_array.toString());
} catch (Exception e) {
e.printStackTrace();
logger.error("Error description", e);
} finally {
try {
DBConnection.close(fetch_all_pstmt, fetch_all_Rset);
} catch (Exception e) {
logger.error("Error description", e);
}
try {
DBConnection.close(dbConnection);
} catch (Exception e) {
logger.error("Error description", e);
}
}
return builder.build();
}
}
Could you please let me know how to secure the REST CALL in this case
You cannot hide an URL from a Browser's network monitoring. It is meant to be displayed so that it can be inferred that what is happening when you hit a button or click something.
Securing a REST Jersey call is a totally different thing. That means you do not want people to see your data that you are going to pass. As correctly mentioned by Martingreber that if you call this URL on HTTPS that may help you encrypt data that you send across the servers. Or securing a REST call actually means you provide some kind of authentication to it . Like Basic , Hashing like MD5, Token based Authentication like JWT.
The only thing that you can do to hide explicit details from your browser that runs your JavaScript is minify your script . But still your URL remains exposed as many times as it is called by someone who fiddles with the F12 key on Chrome to see what's going on. One more thing can be if you are concerned about your main service call, and don't want to expose that , then just PROXY it using some service, which you are already doing . But by no means, you can avoid your URL being getting displayed, when someone calls it.
In your case fetchAllValues service is fetching the data and exposing it to anybody on the web who clicks it, but that can be prevented if you authenticate the service, like the minute i click that URL, it asks me for a password! Then i cannot access it. A very simple way to authenticate this service would to call a Filter or an Interceptor just before the request to ask for username and password like credentials.
I hope you got the point. Hope this helps :)
You will always be able to see the URL that is being processed. Still, you could obfuscate the Service Endpoint to hide the purpose of the service itself, e.g. #Path("/XYZ")instead of #Path("fetchallvalues")
If you want to hide the data that is being transmitted between the client and the server, so noone can read it, simply use https. Depending on your webserver (Jetty, Tomcat) you will have to configure it differently, still you will need a ssl certificate for your domain, which you can get here for example: https://letsencrypt.org
If you want to secure your webservice, so it can't be used by anyone, but only by specific users, you might want to give Spring Security a try: User authentication on a Jersey REST service
This is a problem that needs some smart hacks to fix it.
In the hyperlinked stackoverflow page, you will get an example of how to make a SOAP request from client side JavaScript.
SOAP request from JavaScript
Now here's the plan:
In the server side, we have a random number generator, which generates a random number in short intervals, say 5 minutes.
The random number generator will be exposed as a SOAP service and it will produce the random number generated.
From the client side, we will invoke the SOAP random generator service (refering to the stackoverflow page mentioned above) and get the generated random number as the response. We will invoke the service from a JS function which will be fired when your page is loaded (onLoad). So, now we have the random number at the client side.
Then, we pass the random number as a path param in the GET request URL of the REST call and fire the GET request.
In the server side, once the Rest GET request is received, we check if the number received as path param is the same number that is generated in the server side.
If the numbers match, then we give the required response, else do not send the response.
Here we are trying to introduce an unique key, which is the random number generated at the server side. This unique key, when passed as the path param of the Rest GET request URL, serves as an identity of the origin of the Rest GET call. For someone who wants to invoke the Rest Api by referring to the Network Tab of the Chrome Dev console, will not get the unique key for a long time ( as it is refreshed/regenerated after every 5 minutes). Thus the hacker will not be able to use the Rest Api for a long duration. Also, since we are transporting the unique key (the random number) from the server to client side using SOAP, it is not possible for the hacker to get it from the Chrome's developer console.
Hope this approach helps!
Unfortunately, there is nothing you can do to prevent the client from inspecting the requested URL. But you always can require credentials to access your API endpoints.
Authentication in REST APIs
In REST applications, each request from the client to the server must contain all the necessary information to be understood by the server. With it, you are not depending on any session context stored on the server and you do not break the REST stateless constraint, defined by Roy Thomas Fielding in his dissertation:
5.1.3 Stateless
[...] communication must be stateless in nature [...], such that each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client. [...]
When accessing protected resources (endpoints that require authentication), every request must contain all necessary data to be properly authenticated/authorized. And authentication data should belong to the standard HTTP Authorization header. From the RFC 7235:
4.2. Authorization
The Authorization header field allows a user agent to authenticate
itself with an origin server -- usually, but not necessarily, after
receiving a 401 (Unauthorized) response. Its value consists of
credentials containing the authentication information of the user
agent for the realm of the resource being requested. [...]
In other words, the authentication will be performed for each request.
Basic authentication
The Basic Authentication scheme, defined in the RFC 7617, is a good start for securing a REST API:
2. The 'Basic' Authentication Scheme
The Basic authentication scheme is based on the model that the client
needs to authenticate itself with a user-id and a password for each
protection space ("realm"). [...] The server will service the request only if it can validate
the user-id and password for the protection space applying to the
requested resource.
[...]
To receive authorization, the client
obtains the user-id and password from the user,
constructs the user-pass by concatenating the user-id, a single
colon (":") character, and the password,
encodes the user-pass into an octet sequence,
and obtains the basic-credentials by encoding this octet sequence
using Base64 into a sequence of US-ASCII
characters.
[...]
If the user agent wishes to send the user-id "Aladdin" and password
"open sesame", it would use the following header field:
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
[...]
Token-based authentication
If you don't want to send the username and the password over the wire for every request, you could consider using a token-based authentication. In this approach, you exchange your hard credentials (username and password) for a token which the client must send to the server in each request:
The client sends their credentials (username and password) to the server.
The server authenticates the credentials and generates a token.
The server stores the previously generated token in some storage along with the user identifier and an expiration date.
The server sends the generated token to the client.
In every request, the client sends the token to the server.
The server, in each request, extracts the token from the incoming request. With the token, the server looks up the user details to perform authentication and authorization.
If the token is valid, the server accepts the request.
If the token is invalid, the server refuses the request.
The server can provide an endpoint to refresh tokens.
Again, the authentication must be performed for every request.
The token can be opaque (which reveals no details other than the value itself, like a random string) or can be self-contained (like JSON Web Token).
Random String: A token can be issued by generating a random string and persisting it to a database with an expiration date and with a user identifier associated to it.
JSON Web Token (JWT): Defined by the RFC 7519, it's a standard method for representing claims securely between two parties. JWT is a self-contained token and enables you to store a user identifier, an expiration date and whatever you want (but don't store passwords) in a payload, which is a JSON encoded as Base64. The payload can be read by the client and the integrity of the token can be easily checked by verifying its signature on the server. You won't need to persist JWT tokens if you don't need to track them. Althought, by persisting the tokens, you will have the possibility of invalidating and revoking the access of them. To find some great resources to work with JWT, have a look at http://jwt.io.
In a token-based authentication, tokens are your credentials. So the tokens should be sent to the server in the standard HTTP Authorization header as described above.
Once you are using Jersey, you could have a look at this answer for more details on how to implement a token-based authentication in Jersey.
HTTPS
When sending sensitive data over the wire, your best friend is HTTPS and it protects your application against the man-in-the-middle attack.
To use HTTPS, you need a certificate issued by a certificate authority such as Let’s Encrypt, that claims to be a free, automated, and open certificate authority.
I need to do a POST request to get the access token from Google Analytics using a service account.
I need to bypass manual authorisation in a browser, so I have used a service account for which I have all the details, private_key, client_id, etc
https://www.googleapis.com/oauth2/v4/token&grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer&assertion={PRIVATEKEY}
If I do the above, I receive not found.
Can anyone help?
Cheers
The Server Side Authorization Embed API demo has an example of doing this. The example uses the Google APIs client library for Python, but, as #DalmTo mentions in their comment, you could look at what it's doing under the hood to replicate the requests.
Here's what the code that gets the access token looks like:
import json
from oauth2client.client import SignedJwtAssertionCredentials
# The scope for the OAuth2 request.
SCOPE = 'https://www.googleapis.com/auth/analytics.readonly'
# The location of the key file with the key data.
KEY_FILEPATH = 'path/to/json-key.json'
# Load the key file's private data.
with open(KEY_FILEPATH) as key_file:
_key_data = json.load(key_file)
# Construct a credentials objects from the key data and OAuth2 scope.
_credentials = SignedJwtAssertionCredentials(
_key_data['client_email'], _key_data['private_key'], SCOPE)
# Defines a method to get an access token from the credentials object.
# The access token is automatically refreshed if it has expired.
def get_access_token():
return _credentials.get_access_token().access_token
https://github.com/merle-/silhouette-rest-seed
I am trying to use this as I don't want to use the scala.html template files, and this seemed to do exactly what I wanted. I can CURL to create a user and get a token, but I don't know what to do with the redirects when trying to authenticate with a social provider, such as Facebook. There don't seem to be any instructions, either. Any help would be appreciated.
The readme gets you to the point where you have signed up a user and with the credentials POST retrieved the X-Auth-Token.
After a little debugging you will submit a POST request to the auth/link route to associate the user with the returned X-Auth-Token with a social provider as in:
http :9000/auth/link/facebook 'accessToken=xxxxx' X-Auth-Token:tokenfromearlier
Note the syntax of httpie is specific and must use = for json and : for headers. You obtain accessToken from here: https://developers.facebook.com/tools/access_token/
This will return the following JSON:
{
"message": "link with social completed!",
"status": "ok"
}
Not yet sure how to accomplish the next step which is to invoke the
/auth/signin/facebook POST route as this requires the ID of the provider and I am still figuring out the fb graph access approach.