Does this mean Zoho API documentations are wrong?
I'm following the "client based applications" as my app is a ReactJS based app. Unfortuantely im getting a fetch failed type of error when trying to request an authentication token using response_type = token.
Very frustrating indeed.
What is the proper way to get an auth token for ReactJs apps?
You can get it by chrome(or firefox)
Get format (make single line)
https://accounts.zoho.com/oauth/v2/auth?
client_id={your client id}&
response_type=token&
scope=AaaServer.profile.Read&
redirect_uri={your app redirect URI}
This is steps
Get client_id and redirect_uri from my Zoho Setting
https://api-console.zoho.com/
Make single line string with upper format
put that string and enter from Chrome
The client id and redirect URI should be match your App settings.
Click the Accept button with checked Grant access checkbox
Will get the access token at address editor in Chrome
Get new access token with this format
http://localhost:3000/#&
access_token={get-new-access-token}&
expires_in=3600&
location=us&
api_domain=https%3A%2F%2Fwww.zohoapis.com&
granted_for_session=true
You can make your React app for getting access token with this steps.
Related
I am using Laravel as my backend together with Sanctum which generates personal access token for mobile users. For my mobile application I am using flutter.
To authenticate users they login with their username/password and get a personal access token in return. This works but requires a user to login every time they open the application again so I did what most tutorials suggest which is saving the token on the mobile device using shared preferences/secure storage.
Now comes the question how do you invalidate a user when you remove their token from the backend? On initial login it appears everything is still fine because like in most tutorial I check for the existence of a token. After that whenever I want to make a request which uses the token I obviously run into problems because it not longer exists on the backend.
Most tutorials/guide suggest saving the token and using that a reference to see if the user is logged in or not but this seems flawed because it gives the false impression you actually have a valid token.
My guess is this can be solved by always performing a heartbeat/ping action to check if the current token is valid and if not send them to the login screen instead of simply checking for the existence of the token.
Thoughts on this?
I can suggest a hack or trick here in every launch of the app you can send a request to an API to check if the user's token is valid or not and if it is valid then you can continue the app otherwise force the user to login and generate new token this way your app will be secure via server / API.
For this, you can store the user's secret token in the database and check it via HTTP API call and send a response from the API accordingly and check the response in app and do the next operation according to the response you get.
I don't know if this is a great way of doing this job but it is a kind of hack/trick to achieve what is needed.
Thanks
I'm trying to upload and publish my Chrome Extension using Chrome Web Store API in Azure DevOps. I've been referencing the official Google guide but the problem is that it looks like it's outdated now. I'm failing at the step
To create the client ID and client secret, click on Create New Client ID, select Installed Application, and Other under Installed application type.
When I do this, I don't see option for "Other" in Application Type dropdown.
I've tried the following:
Choosing Web Application as Application Type
With this I'm not able to get an access code with this link:
https://accounts.google.com/o/oauth2/auth?response_type=code&scope=https://www.googleapis.com/auth/chromewebstore&client_id=$CLIENT_ID&redirect_uri=urn:ietf:wg:oauth:2.0:oob
it's resulting in "Error 400: redirect_uri_mismatch". If I add an authorized redirect URI in my Client ID settings, like 'localhost', and replace 'urn:ietf:wg:oauth:2.0:oob' in URL above with it, I'm able to invoke authorization process and get the code from URL. But when I try to make a curl request to https://accounts.google.com/o/oauth2/token to get the refresh token I don't receive a refresh token, I only get this:
{
"access_token": "",
"expires_in": 3599,
"scope": "https://www.googleapis.com/auth/chromewebstore",
"token_type": "Bearer"
}
Choosing Chrome App as Application Type
Pretty much the same happens here as in previous attempt, except I don't have to substitute the redirect URI in request for access code, but I also don't have Client Secret for this application type, so I just omit it. Anyways, it results in the same response that doesn't have refresh token.
When I enable Chrome Web Store API in dev console and try to create new credentials, it suggests to create API key instead of Cliend ID. But it doesn't look like this API can actually work with this key, I've tried sending it as query param, as a header, and I always get 401 result with "Login Required" message. But when I try to send a request with (invalid) token in a header I get meaningful response (smth like Invalid Credentials).
Apparently I do need to have access token to work with Chrome Web Store API but without refresh token I need to manually authorize my permissions and that's not acceptable because I need to use in my CI/CD pipeline. It looks like Google removed the option to just generate this info for such application types.
So, the question is, how can I get the refresh token to actually be able to continuously deploy the chrome extension?
Ok, so the trick here was to add two params to the request that you use to get the access code (not token):
&access_type=offline&approval_prompt=force
And so the link should be:
https://accounts.google.com/o/oauth2/auth?response_type=code&scope=https://www.googleapis.com/auth/chromewebstore&client_id=$CLIENT_ID&redirect_uri=urn:ietf:wg:oauth:2.0:oob&access_type=offline&approval_prompt=force
And Google should do better job in updating their docs.
We are creating a Xamarin Forms app, only Android for now, which connects to a web API also created by us (ASP.Net Core). I have managed to get OpenId Connect authentication working by:
Using Azure as the identity provider.
Using Android custom tabs to show the Microsoft's login page.
Detect when the custom tab is redirected to our redirect URL.
Get the id token and use it as the authentication bearer token sent to our web API.
Using JwtBearer authentication in the web API.
The problem appears when the id token expires. We want to get a new one without asking the user any question.
To do that, we repeat the authentication process by adding the prompt=none, id_token_hint=THE_TOKEN and login_hint=THE_USER parameters in the authentication request, as defined in the OpenId Connect specification, and supported by Azure.
During that request, we have an issue with the redirect URL:
If the redirect URL has a custom scheme (like myapp://...) Azure responds with an interaction_required error.
If the redirect URL has an HTTPS scheme, then Azure responds successfully (including the necessary parameters to continue the process), but I am not able to detect the redirect URL in the Android custom tab. So my app gets stuck in the custom tab trying to load my invalid redirect URL.
The explanation for #2 is that HTTPS URLs are handled by the browser (Chrome in this case), so it does not trigger any action that I can detect from my app. This seems reasonable.
I also tried to detect custom tab navigation events from Xamarin, trying to detect the event "manually", but failed. Such events are never triggered.
Now, as for #1, I do not have any reasonable explanation. So my question is:
Is there any way to make Azure accept a redirect URL with a custom scheme when trying to refresh an id token by using the standard prompt=none OpenId Connect parameter?
I started a project using the Google API signin mixed with an angularJS+Firebase app.
What I would like to do is to be able to send an e-mail from one person to another programmatically.
Example: John is logged in, clicks on a button which sends an email to Rachel. But that email is sent using the stored token from Ted, not John's account.
It seems possible using the php library which is not an option here.
So far, I get the token easily using these few lines:
var GoogleAuth = gapi.auth2.getAuthInstance();
GoogleAuth.grantOfflineAccess({
scope: 'https://www.googleapis.com/auth/calendar https://www.googleapis.com/auth/drive https://mail.google.com/ profile email'
}).then(function(resp) {
console.log(resp);
this.storeToken(resp.code);
});
Is it actually possible ?
A quick search just got me results for php or about how you get a token with the JS library... not how to use it !
From my understanding you want to use a refresh token ( offline access ) to send an email from Ted's account via Javascript.
Sadly this is not possible client side. What your code gives you is a 'code' that you can send to your server using a $http.post () and trade with Google server side for a refresh token.
Here is a guide for how to change that code into a refresh token.
While you can do this client side it would involve exposing your client secret which you should never do.(https://developers.google.com/identity/sign-in/web/server-side-flow)
Every time John wants to send an email from Ted's account your application will have to send a request to your server that:
Sends a request to google with the refresh token and generates an access token (https://developers.google.com/identity/protocols/OAuth2WebServer#offline)
Sends a seccond request to google using the access token to send the email from Ted's account
I hope that this helped.
We would like to enable WeChat Login on our iOS client that is connected to a Parse Server backend on Heroku. From reading through the PFFacebookAuthenticationProvider, it seems that we need to write a custom authentication provider for WeChat.
WeChat Login is based on OAuth 2.0. It works as followed:
1. From our app, an authorization request is sent to the WeChat app installed on the same phone. WeChat app is called to the foreground.
2. After user approved the authorization request, a code (NOT the access token) is sent to our app.
3. With the code and our app id and app secret, our server can then call WeChat API and get the appropriate user id and access token from WeChat. This step has to happen on our server, as we cannot include the app secret within our client app.
On the WeChat documentation, it is strongly recommended that we keep the access token strictly in the control of server (anyone with the access token can make requests to WeChat API and it will be counted towards the usage limit for our API calls).
If we are to follow this practice, we cannot save the access token in the authData field of the user. Would it be acceptable to save only the code and id from WeChat into the authData and save the access token to another class that only the master key has access to? This obviously requires us to write a custom AuthAdapter for the Parse Server.
Or is there a better way to implement this custom auth? The custom auth documentation for Parse Server is pretty thin and I plan to improve it after I can get it working for myself.
You can definitely update the auth adapter to exchange the code for an access token server side. The logic would be similar to other adapters, failing to login/signup if the server is unable to process the code to access token exchange.
Here
https://github.com/parse-community/parse-server/blob/master/src/Adapters/Auth/wechat.js#L7
If the authData object has that code, you can add additional logic to exchange it.