I have a Java server that consumes and produces JSON. In my Dart login form, I post to the server and the server will respond with a credential if I'm logged in (using UUID.randomUUID()).
Now every time I need to do something like update a user, I need to send along this credential. My concern is:
Since the Dart app is HTML and Javascript, will it be secure to save this in a Dart variable and then access it when I need to do some operation to the server? I understand that I should use HTTPS but I'm just wondering...
HTTPS secures just the transport between client and server. That doesn't help anything with the variable you save the value in.
If you control the server you could use a secure cookie that gets sent to the server automatically but isn't accessible from the client.
If not you won't have much alternatives.
Related
As I understand, in authorization code flow we need to get authorization code and use it to get token after. We can get this code only when user confirms specified access. After that browser redirects us to redirect_uri and response will contain authorization code as parameter. So, the question: is it possible to get this authorization code without browser or any self made UI? Can we get it in application after correct request to, for example https://mysite.tuz/authorize ?
As you are using authorization code flow, the client requires a user agent (i.e browser or mobile app) to get the authorization code from the authorization server.
The whole purpose of using authorization code is that it can be passed via the user's web browser (user agent) instead of passing the access tokens directly via the web browser (user agent) which is not desired. Using authorization code,the Client then can directly retrieve an Access Token from the authorization server.
So the user agent is required to get the authorization code and act as an intermediary between client and authorization server.
If you do not require a browser then authorization code flow may not the correct choice. OAuth 2.0 supports several different grants i.e ways of retrieving an Access Token. Deciding which one is suited for your case depends mostly on your Client's type.
This might help you in deciding which flow to use
https://auth0.com/docs/api-auth/which-oauth-flow-to-use
You should use client credentials to obtain token without browser or any client. But if you need to use user credentials to get access token and id token of the user without browser or mobile app you need to implement you own client which will do the necessary logic for you and fetch the token for you. I already did it in java for the testing purpose. I don't know why you need to do it but you can implement your own client in almost any programming language . But in case you will decide to go this way you have to handle lot of things.
I expect your authorization server requires Proof-Key for Code
Exchange (PKCE) - so first of all before you start to communication
with server you have to create code verifier and code challenge
(google can help you with that :) in java it is quite simple)
Then you should start communication with server sending get request to url which ends with 'auth' you should send query params as: response_type (which is 'authorization_code' in your case), redirect_uri, client_id, code_verifier, code_challenge, scope, code_challenge_method (probably 'S256')
Then you receive I think two redirects from server so it is better to have some client in java which will automatically call those redirects. I used apache http client for my implementation. It has lot of features.
After successful redirect server will return login page to your client. It depends on authorization server but in this page you should put the data as username and password and submit the page. I have simply parsed the returned page and get the url for user authentication from it and simply make post request to that url with user credentials data sent in encoded form entity. In apache http client you will have all cookies from previous communication set (until you close the client) since apache http client automatically set all cookies returned in previous communication from server.
After make authentication request server will send you two redirects and you can store those redirects int http client context which you will provide for http client when you call authentication url.
In the last redirect there will be query parameter sent be server named "CODE" this is really important for you since you will use it to get token from the server
And finally you have to make one last post request to authorization server with url ended as token. So make a post request with GRANT_TYPE, REDIRECT_URI, CODE (you received in previous redirect), CLIENT_ID, CODE_VERIFIER (you have generated at the beginning);
Then authorization server will send you token and that's all
We have a Client Server Based Java Product, I need to integrate google OAuth in server dashboard where our client can sign in and allow access to gmail API. After that, server will use REFRESH TOKEN and ACCESS TOKEN to send Email reports to some emails Ids using client gmail Via Java Mail API.
We need to implement sign in only once and send mails forever i.e. Offline Access (Means REFRESH TOKEN is compulsory).
Our product is deployed as in premise as well as cloud based (At a time only one). Thus in client environment we can have private ip or public ip or public ip mapped to dns.
I know there are two way in which this can be done:
1) server side authentication
2) client side authentication
In Both cases you need public dns mapped REDIRECT URI ie a url where google will redirect the user after sign in. But in our case, we dont have
always a public domain mapped to client server machine. Also we cannot provide localhost in redirect uri as well.
SO
PROBLEM I: What should be used in place of REDIRECT_URI
PROBLEM II: We have many clients so should we use one application for each client or we should deploy a single application on cloud, where each client dashboard will be redirected while sign in and in response we will get token.
Any other alternatives for above problem will be appreciated.
Ok i got the architecture.
Google apps give the flexibility to add multiple java script origins and redirect uri's.
So we need to create only one app in developer console. For each client, we will add a authorized java script origin and redirect uri in google app online. And when sign in button will be pressed in client's server we will give redirect uri accoring to that client which is already added in google app. For private ip there is no solution, but localhost can be used with the restriction to sign in from browser on server system.
I have been struggling over the past week to get the ideal configuration for my implementation. Basically, I have a Salesforce Page which makes a REST callout containing some data to be computed, A Heroku server then computes this data before sending the computed data back to SF in the response. This all happens in the background and so no Heroku front end exists.
I want to protect this callout with oAuth2, but I'm not sure the best way to do it:
The data itself is not important, its the access to the heroku app which is.
If I use salesforce for authentication, it means that the callout structure doesn't work (I would have to implement a system for Heroku to grab the data from SF before returning it) which isn't ideal and I can't see a way to use Heroku authentication as it allows access to the api but not the app script in a single structure. I think I have to create my own authentication server within Heroku but I'm not exactly sure if this is the correct way of going about it.
Any tips would be greatly appreciated
This is my callout code from SF:
Http http = new Http();
HttpRequest request = new HttpRequest();
//Sets the url to heroku
request.setEndpoint('My App URL');
request.setMethod('POST');
request.setHeader('Content-Type', 'application/json');
//places the content into the body
request.setBody(content);
//Extends the read timeout
request.setTimeout('120000');
//Sends the request and waits for a response
HttpResponse response;
response = http.send(request);
Heroku Side:
post("/", (req, res) -> {
//creates a local var for the JSON string
String data = req.body();
//--** The server then computes this data and calculates output
String computedData = compute(data);
return computedData;
});
I need a way of authenticating this type of connection, Thanks!!!
Did you read the Heroku guide to OAuth? It's pretty helpful. The flow would be:-
Salesforce app issues a redirect to your Heroku - GET https://id.heroku.com/oauth/authorize?client_id={client-id}&response_type=code&scope={scopes}&state={anti-forgery-token}
After user has authorized access there is a callback to your Salesforce app with an exchange token
You Salesforce app then needs to exchange the token for an Access token with your Heroku app with the relevant scopes to access the data at Salesforce
I'm not sure if this is what you want though since the whole point of OAuth is not authentication but authorization ie. the OAuth flow is not designed to identify the user, but to enable you client (Salesforce in this case) to access the user's resources held by the provider (your Heroku app in this case).
Since you want Authentication, not Authorization, there are a couple of approaches you could take depending on how much work you want to put in vs how secure it needs to be (you have to make a call on this).
Quick and dirty but not very secure
You could just check the referrer Header on Heroku and if the client is anything other than your Salesforce app then you return a 403 Forbidden or 401 Unauthorized. It's not very reliable since referrer is not overly reliable but its quick and straightforward if you do not have a great understanding of authentication and just want something quick and basic.
Send a client ID with each request
This could be a Header or be in the body of the request. For it to be secure though you will need to encrypt it since you say you do not want to use SSL/TLS. So you will need to encrypt/decrypt the client ID at each end.
A basic approach is to just use some symmetric key that you share between your client (Salesforce) and provider (Heroku) which you store securely within each app somewhere so that hackers cannot read it. You also share (and securely store) some ID string (ideally some long random hash).
The flow would go like this:-
Salesforce app takes the random ID string and uses the symmetric key to encrypt it. This is what you send in the request to your Heroku app.
Heroku app - on receiving an incoming request - reads the encrypted value. It then uses the symmetric key to decrypt it. Your Heroku app then compares the decrypted value passed in the request and the random ID string (it also has stored locally) and if they are the same you have some degree of confidence that the source of the request was your Salesforce app. If not you deny the request.
Authentication is a big subject, as is encryption. If you really need to protect the data and there is a risk of you being sued if you do not, then you need to do some more research. If the data is not sensitive (or particularly valuable to anyone else) and you are just trying to have some basic front gate which reduces other applications from exerting a load on your application then you could consider just checking the referrer as a first attempt.
I am trying to call a php script from my android app to pass some data and store it in the database. Is there a way to allow access to php script from my android client only?
Thanks.
You can add accessToken in every httpRequest, and server will identify that accessToken & will respond appropriately.
NO, The only thing that has information about the client is HTTP User Agent that will be sent within HTTP Request header, but header information must not be used for security because header can be faked and changed, therefore, you can depend on unique parameter (public not private) to be sent to your PHP server from Android client, for example send Unique Identifier with all request such as (page.php?android=UNIQUE_ID) then you can check this identifier from your PHP script. Again, this approach is also not secure and not reliable.
Hey all I was trying to create a java program which will remain logged in on server whenever i browse on website no authentication will be required even if i run the program later on i.e. my program should store some cookie file on client side and also tell the browser that this session should lasts for quite a long time. And whenever i run the program this should send the cookie details, that this is recognized and the user is logged on, to the server.
So how this should be done using HTTP protocol.
Thanks. :)
The browser (client) stores a session cookie containing a key-value pair. The key is usually JSESSIONID, and the value is a unique identifier. It is received by the client as a response of his request to the server, which initiates the session.
Whenever a request is made to the server, the browser sends that key-value pair in a special http header ("Cookie"). The server then reads that header, obtains the identifier, and finds the corresponding session.
Why don't you guys use Google before asking?
See the following:
HttpURLConnection class
HTTP cookies description
How to use HTTP Cookies in Java