Looking at the docs for the appRequest for actions on google https://developers.google.com/actions/reference/rest/Shared.Types/AppRequest
The user object says that the userId property is now deprecated and that we should use the idToken instead https://developers.google.com/actions/reference/rest/Shared.Types/AppRequest#user
However testing out a V2 action in the simulator, my response only includes a userId property and not the idToken
I'm definitely using V2 of the API and this doesn't say it's an optional field when linking accounts (for what it's worth I haven't done any account linking).
Should this field be included?
That's not quite what that page says.
Yes, it says the userId property is deprecated - it does not show any replacement there. It was deprecated without a direct replacement, although you can create one yourself if needed.
It does not say the idToken replaces it, although you can get a unique ID from the idToken, it doesn't do so directly. It also doesn't give you the idToken unless you take some steps to enable it.
To use the idToken to get a user identifier, you need to do a few things:
Turn on Google Sign In for Assistant.
Request the user sign into your Action using Google Sign In for Assistant or have them sign via other means (Google Sign In for the web or for mobile) to the same project.
When you get the idToken, verify and extract the JWT payload. If you're using the action-on-google library, it will do this for you. If not, this is a standard JWT token which you should verify and the payload includes the ID.
Related
I'm trying to integrate paypal checkout in my website which has a deprecated paypal integration. I'm using server side SDK and I can create and capture a payment with no problems. To do so I'm using clientId and secret generated in paypal Dashboard.
However, in the official documentation it talks about an Access-Token to call APIs but I'm using clientId/secret to do so and until now I haven't had any problems, so what is it for or when is it used?
I also noticed that whenever I made a create order, one of the returned links has "token=XXXXXXX".
Please help.
The client ID and Secret are used to obtain an access token. They are not used for anything else.
An access token is then used for all other REST API calls.
If you are using a server-side SDK, handling of the access token is abstracted by it. You do not need to do anything.
I am currently developing financial services as a personal project.
In order to strengthen security in the project, it is designed and implemented to process authentication at the gateway stage using AWS API Gateway.
I tried to log in using a mobile phone number and the received authentication number, and I don't think this is appropriate for Cognito and IAM identifiers, so I'm going to run the Node Auth Server that issues and verifies JWT tokens in AWS Lambda.
In the process, I tried to include an identifier such as user_id or uuid in the payload of the JWT token, but my colleague opposed it.
His opinion was that access token should only engage in authentication and that the token should not contain a user identifier.
I agreed with him to some extent, but if so, I wondered how to deliver the user identifier in an API such as "Comment Registration API".
Should we hand over the user identifier along with the access token to the client when login is successful?
in conclusion
Is it logically incorrect to include the user identifier in Access Token's Payload?
If the answer to the above question is yes, how should I deliver the user identifier when login is successful?
I wanted to hear the majority's opinion, so I posted it.
Thank you.
Typically you want enough information in the access token so that you can also do proper authorization about what the user/caller is allowed to do.
Typically, you separate authentication and authorization like the picture below shows:
So, to make an effective API, you do want to avoid having to lookup additional information to be able to determine if you are allowed to access some piece of data or not. So, I typically include the UserID and some other claims/roles in the token, so that I can smoothly let the user in inside the API.
However, adding personal information in the access token might have some GDPR issues, but sometimes it might be necessary to also add. But I don't see any issues adding information like UserId and roles in the token.
Yes it is logically correct and a normal thing to do. To see how to do it in a Node Auth Server, you can look at this: https://auth0.com/blog/complete-guide-to-nodejs-express-user-authentication/
I'm using Stripe API(REST) and I need to put a link in email where user can directly unsubscribe/delete subscription(https://stripe.com/docs/billing/subscriptions/canceling-pausing).
I need to know if it is possible to put the arguments and operation in a URL so that when user clicks it, Stripe api is called and subscription is cancelled.
thanks in advance.
The short answer is NO.
Cancelling subscriptions from Stripe API requires your Secret Key which you should NEVER expose in the front end and made public because user will have access to your stripe account in that case.
Saying that, what you could do is to expose an endpoint in your own web server, which you will need to
1) create a on time use token which you can look up your customer and related subscriptions; include the token in your URL send to the user
2) when user click the the url, verify the token (valid non expired) and find the customer and subscriptions
3) Call stripe API with your secret keys to cancel the subscription for the customer.
Our application uses oauth2 & openid connect for auth&auth. It's built using an angular client that calls a REST API. I would like to know how to authorize access to the API, based on the possession of an unguessable url.
I'll explain this a little more. In the application, a user can invite another user. When this happens, an email is sent to the second user. When user 2 clicks a link in the email, he is sent to a webpage with details about the invitation.
Only user 2 should be allowed to see the invitation page. I was planning to solve this by using an 'unguessable url' in the email. Upon visiting the url, the user must somehow be authorized to fetch the invitation details from the API.
The question: how do I authorize a user, based on knowing the unguessable url? How do I assign a claim when the page is loaded, and how do I verify this claim in the API call that follows? The only solution I see, is to set a cookie containing a token. But this is not in line with our existing auth mechanism. I prefer not writing my own token validation code, and let the Identity Provider handle this.
Additional info: user 2 may or may not have an account in the system, and he may or may not be logged in. Neither should prevent the user from seeing the invitation details. In other words: a totally unknown user should be able to see the page. The knowledge of the url should be the only requirement.
Any solution to this problem? Or am I handling it all wrong?
After asking around, the general consensus is to NOT let the external auth mechanism take care of this, but to validate the link ourselves.
The solution is to turn the unguessable part of the url (the 'link id') in some kind of token, which can be validated upon calling the API. This is done by the API itself, not by the Identity Server.
Applied to the invitation issue: when an invitation is created, store the link id together with some info, i.e. what kind of access it allows (invitation access) and the id of the invitation. When the user calls the API to get the invitation, pass the link id for validation. Match the invitation id with the invitation id stored in the link, and if it doesn't, throw an error.
I'm trying to implement Twitter SSO in my iOS5 app and saw Twitter had something called Reverse Auth. Can someone shed some light if this is the correct approach to take. Is Reverse Auth basically getting the access token from the iOS5 app and passing that along to the application server?
You only need to use Reverse Auth if you want to allow a server to make API calls. If you're only interested in letting the iOS app post to Twitter directly, then you don't need Reverse Auth.
For Reverse Auth, see:
https://dev.twitter.com/docs/ios/using-reverse-auth
https://github.com/seancook/TWiOS5ReverseAuthExample
Be sure to request Reverse Auth permissions from Twitter first, or else the sample code won't work.
To get your Access Token on Twitter your request must be Authorised Request or Signed request it something like Signed Certificates from Apple when you want to implement Push Notification in your Application.
In Facebook Side these process is made implicitly, but in Twiteer you should Authorize your request first to get user Access Token.
So The main idea n Reverse Auth is these..
you make your First request first with some data like consumer key (which is app key) and consumer secret key.. ( https://api.twitter.com/oauth/request_token )
then you receive a key which you use it in Second request to get the access token..
( https://api.twitter.com/oauth/access_token )
Twitter is using something called Reverse Auth to answer this 4 questions :
1. Which application is making the request ?
2. Which user the request is posting on behalf of ?
3. Whether the user has granted the application authorisation to post on the user's behalf ?
4. Whether the request has been tampered by a third party while in transit ?
and to answer for these questions they added 7 thing to the request you make
oauth_consumer_key
oauth_nonce
oauth_signature
oauth_signature_method
oauth_timestamp
oauth_token
oauth_version
many of people tried to make these by themselves but it will take a lot of time from you to make them by your self and them to your request.
So follow this repo on gitHub
https://github.com/seancook/TWReverseAuthExample
also the documentation of Twitter about Reverse Auth
https://dev.twitter.com/docs/ios/using-reverse-auth