I can see in sendgrid API we have a call to verify a single sender with a token
https://docs.sendgrid.com/api-reference/sender-verification/verify-sender-request
but I can't find a way to actually receive this token from anywhere, the only way is by sending an email that needs authentication (and we fall into this issue verifying sender email requires user to log in to sendgrid)
Anyone actually used this route in a way ?
There is a workaround as follows:
The link in the email redirects to a URL that looks like this https://app.sendgrid.com/settings/sender_auth/senders/verify?token=xyz, with the token query parameter. You can use that token in the api call to verify the sender email using your own api credentials.
Related
I am creating an envelop Via Rest but I want the From of the envelop to be somebody else. It seems like it's not possible to create an envelop on behalf of another account.
Has anyone experience something similar?
Correct, the "from" field cannot be set in the API directly.
It is derived from your access token you obtained to make API calls.
This access token represents some user in DocuSign, that user makes the API calls - therefore, that user is the sender ("from" them the envelopes come).
One way to "send on behalf of someone" is to use JWT authentication. With JWT, you provide the userId for the user that will be impersonated. That user will be then the "from" for your envelope. If you want to send multiple envelopes and wish each of them had a different "from" field, you would have to obtain multiple access tokens with different userIds.
Lastly note that JWT requires the user to agree (consent) to you impersonating them. This consent is only required once and then your integration is authorized forever (the reason is that I wouldn't like your code to be able to send out envelopes coming from me without my consent, right?)
Desired result:
User should be able to register and then he should be able to login thrugh a mobile app (event if the email address isn't verified), the app shows a warning that email isn't verified and some app functionality a disabled
What i have:
native mobile app that has user signup and signin functionality
api server consumed by the app
keycloack instance
signup functionality is done by api server, it is a keycloak confidencial client that can create users
signin is done by the mobile app directly with a post call to keycloak /token endpoind that returns access token
all good, now i have a token that can be consumed by my api server and i know that it is a registered user with unconfirmed email address
The problem is that user don't receive any Welcome/Confirm email, but: if user goes to keycloak LogIn webpage and try to login with newly created user then he receives an email from Keycloak, but for LogIn through api there are no emails. Is there any way so solve this? Am i doing something wrong?
The only way to request user to verify emails is by requesting "Verify Email" action, but if i do this then user can't login with unverified email anymore
Login is done with POST to /auth/realms/realm/protocol/openid-connect/token and with {grant_type: 'password', password: 'string', username: 'string'} body
Calling PUT /{realm}/users/{id}/send-verify-email seems to behaves the same like requesting Verify Email to /execute-actions-email
I know I'm a few years late for this answer, but for anyone who comes here in the future, the devs answered in this thread here
This is a limitation with the execute actions endpoint and it uses a
generic email. It's not a bug, rather a limitation
And that's it. They have a specific endpoint just to send an email of verification but it's only a wrapper to the endpoint execute-actions-email
I am currently using a client-side React component to have a user login to Facebook via OAuth in my application. On the server-side, I use the npm package passport-facebook-token to validate the authenticity of the accessToken after a successful client-side login.
One practice I do not see often is in addition to asking Facebook if the accessToken is valid, shouldn't the server also check if the email provided by the client's payload matches the e-mail coming back from Facebook? Allow me to use defined client/server technologies to illustrate my question:
1) User uses React component on the client to authenticate with Facebook.
2) React component successfully authenticates with Facebook and fires an HTTP request to the server with an access token and the user's email.
3) The server, running Node.JS and passport-facebook, now needs to verify the authenticity of the access token directly from Facebook. Facebook does not care for an e-mail. It will just verify the access token.
4) Facebook returns a response to Node.js confirming the authenticity of the access token. The response also contains other metadata about the user, including their email and other profile data.
My question is, should Node.js take the email that's also coming back from Facebook's access token verification payload, and verify that it is what came back from the React client? Would this not prevent someone from brute-forcing an accessToken and require them to not only have an accessToken but also know who the accessToken belongs to? This could prevent a user from submitting a bunch of HTTP POST requests to the Node.js server attempting different access tokens. They would not only have to guess an access token assigned to the application's clientID, but also know the e-mail it belongs to. Is this an over-engineered approach?
Really the best way I can think of to make your OAuth accessToken and 'code' value less prone to brute-forcing is using a Cryptographic Number Generator to create a 128-bit length string of random data and encoding it with base 64 to use as your code. It's extremely unlikely that it would be guessed by a computer or by someone redirecting to and from the authorization endpoint and the redirect-uri with query parameters.
Another method of fortification is limiting the rate of authorizations by IP address (which you can do instead of email through Node.js) but that is usually not a problem for most well-equipped hackers. I highly advise the first method for creating a more secure service.
Your approach to validate the email as well as the token is a bit superfluous because Facebook's opaque user access tokens are inherently tied to email.
From Facebook
An access token is an opaque string that identifies a user, app, or Page
"opaque" is defined by Auth0 here
Opaque Access Tokens are tokens in a proprietary format that typically contain some identifier to information in a server’s persistent storage
In your case, the identifier is the user's email, and the server belongs to Facebook.
I will elaborate further. Here is your step by step with some edits:
User uses React component on the client to authenticate with Facebook, inputting both their email and password directly to Facebook. React component gets the token from Facebook on login success.
React component successfully authenticates with Facebook and fires an HTTP request to the server with an access token and the user's email.
The server, running Node.JS and passport-facebook, now needs to verify the authenticity of the access token directly from Facebook. Facebook does not care for an e-mail. It will just verify the access token because the access token is already tied to the email.
Facebook returns a response to Node.js confirming the authenticity of the access token. The response also contains other metadata about the user, including their email and other profile data.
This is Facebook's bug bounty program. If their OAuth was really as cracked as to require a second email validation, it would have been patched almost immediately by this incentive.
I have a client (HTML+JavaScript) and a server (ASP MVC) and I need to provide a user some private information. To achieve that I need to verify that
user authenticated and
use users email address to retrieve its
private information.
I want to use FB authentication. It looks pretty straight forward but has a flaw which I am sure people can tell me how to solve or what am I missing.
client initializes FB SDK and requests user to authenticate using FB
result of successful step #1 is access token.
We can place another call to FB using this access token to retrieve
email and name.
How can my server know what is the email and name of the authenticated user?
My understanding that client should not send email and name to the server (it can be hacked and can not be trusted) but instead client should send the received access token, which server should use to get user's email and name, but on the server side.
Please explain, give me an example, point me to a link on how can I achieve that on the server as all my searches for that failed.
One more time, my backend is ASP MVC.
On the server, make a call to the Graph API:
https://graph.facebook.com/me?fields=name,email
Use the Access Token and you will get the correct data:
https://graph.facebook.com/me?fields=name,email&access_token=xxx
Btw, you should also read this: https://developers.facebook.com/docs/graph-api/securing-requests
I guess I was confused with what I need to do in ASP MVC in order to get a user info having an access token.
The suggested link: https://developers.facebook.com/docs/graph-api/using-graph-api helped me to understand that all I really need is to make a HTTPS GET call (from the server) to "graph.facebook.com" passing access cookie (received from the client) to retrieve the information I need and exclude a possibility of hijacked/compromised client passing me a wrong email.
Using GRAPH API means placing https calls to GRAPH.facebook.com - that was no clear to me.
I'm currently using SendGrid's Inbound Parse Webhook to feed emails to my application. I've been able to get it working by pointing the URL to an endpoint which my application has exposed. SendGrid just sends the email in the form of a JSON format HTTP POST request to this endpoint and I just process each request internally.
My question is, now that I have it working, how do I ensure that only SendGrid can use this endpoint? At the moment, anyone can utilise this HTTP POST endpoint and pretend that an email has been sent to the application.
Can I get SendGrid to send some sort of unique key to identify themselves? Is there a way I can restrict by ip address?
There are two ways which you may secure your endpoint. SendGrid's webhooks support basic auth (e.g. https://user:pass#example.com/endpoint). You can also implement a unique key, that you check before acting upon the request (e.g. https://example.com/endpoint?key=123).
The simple answer, however, is anything that you add to the URL can act as unique authentication for SendGrid.