I have a question about fusionauth and its 2FA API.
we want to use 2fa in our app but only under some circumstances and not on every login.
I found that there is API to send a code via SMS but I can't seem to find an API to verify it.
can anyone help me?
I looked at the docs and there is only send and enable/disable no verify, can it be somewhere else?
The API does support a trust mode, but there is not currently a separate API for selective 2FA.
There is not an API to validate the code, instead you utilize the Two Factor Login API to complete the login process. This implicitly validates the code.
https://fusionauth.io/docs/v1/tech/apis/login#complete-two-factor-authentication
Related
my application requires an authorization code grant flow integration with Cognito and the website responded to me that Auth-Code accordingly.
https://<poolName>.auth.eu-central-1.amazoncognito.com/login?client_id=<clientID>&response_type=code&scope=email+openid+profile&redirect_uri=<redirectURI>
Now I want to know what email address has logged in. As fas as I understood, this is where I would need the JWT token.
How can I query the email adress of the token I have just received?
Any help is much appreciated!
As I was going through that, actually, I still am. I have talked a lot with Amazon Engineers for past weeks, have done a bunch of research on my own and let me clarify couple of things.
Hosted UI is a way to go if you can accept the limitations. This is after all hosted ui, you can only change that much. BUT (!!!!) and I can not stretch this enough: it works only for simple usage. If you start searching you'll see that it doesn't support CUSTOM_AUTH flows which is extremely useful if you want to implement even something as basic as MFA. So if you dream of Revolut-like login page with just phone number email verification - pity, hosted ui will not help.
Hosted UI is more than just UI! It's a whole server! That's why you can't simply replace it.
Now, as we established what hosted UI can't do. What are the alternatives? Of course, you can use other providers like Okta or Auth0, but I assume, you're here because you want to use AWS. But the recommended (by AWS) alternative is to actually implement your own authentication using Amplify SDK. It's quite simple to use, I must say that. But what they don't tell you explicitly, is that it's no longer OIDC flow. Instead, AWS suggests to use their custom flows, such as USER_PASSWORD flow or SRP (Secure Remote Password), where password doesn't fly over http(s) at all.
You might ask: can't I have OIDC with Cognito AND custom flows? Well... you can, but it's not that simple. Long story short, you can use both hosted ui and amplify and possibly create your own cool SSO. For details look at their github page where AWS Labs go through some details.
If you can't afford spending next 2 months working on SSO, but you don't necessarily need OIDC flow and get settle for another solution, you can easily go for SRP or USERNAME_PASSWORD flows.
If you're like me and you're migrating from the old legacy authentication system done... wherever (;)), go for USERNAME_PASSWORD and utilise user migration lambda trigger in Cognito, where you can automatically migrate users once they login with their old credentials! Neat
AWS Cognito is full of traps... Consider that as well
First, make sure your Cognito client includes the email OAuth scope. User Pools > my-user-pool > App client settings > Allowed OAuth Scopes.
Then, decode the id token and you will have the email. You can use JWT.io to quickly decode tokens for testing and development.
UPDATE: You can use the POST /oauth2/token endpoint to fetch the tokens. But in general, if you're creating a frontend for users, it's better to use someone else's UI. The Cognito hosted UI works, although it looks a bit dated and it doesn't support MFA/TOTP. The modern approach is to use the Amplify UI Authenticator component, which supports TOTP and all the flows you'd expect (sign-up, password reset, etc).
We are trying to implement Auth0 in our next+fastify based application. The login page is custom and we want to integrate the login using the embedded login from the fastify server.
I am naive to oAuth and Auth0, I have a few doubts around it:
How do we verify the token? Do we verify the JWT and maintain the token on or fastify server or should we always the validate the token on Auth0 endpoint? I tried calling the userinfo endpoint which resulted in rate limiting. So, I interpret if we just verify the JWT on server instead of sending to Auth0 server. Also we send and maintain the JWT in cookies to validate the client always. Is the understading correct?
Is embedded login safe enough to be used in production? Are there any risk associated around it?
Is the approach correct? Is there any alternative way to implement the login flow? We also need to integrate reset password and rest of the functionality. I have read the SDK docs and it seems to have support for all.
Thanks a lot in advance
There are several options to validate a token issued by auth0, they recommend you to take advantage of middleware to verify the token. Multiple frameworks have their own middleware to check and validate JWT. It's as easy as integrate middleware with your application and perform validation when you need it. Check this:
https://auth0.com/docs/tokens/json-web-tokens/validate-json-web-tokens
In my opinion, it is always better to go with the Universal Login option of auth0, since embedded login sometimes incur into the cross origin authentication issue. Remember, when a user tries to log into your application using auth0, it redirects the user to another domain that differs from the one serving your application. In my experience, using the universal login provides you more information about the login process of your users, and that makes the process of debugging errors and auth processes easier. You can read more about login with auth0 here:
https://auth0.com/docs/login/embedded-login
https://auth0.com/docs/login/embedded-login/cross-origin-authentication
Yep, you can integrate the reset password process, which is almost entirely handled by auth0 itself. As I said earlier, we use Universal Login for our applications since it provides more control over the authentication flow. That doesn't mean you can't use Embedded login, it is a very good option too, but it seems more focused in UX rather than control auth flow.
Check this link if you still have doubts about the best approach: https://auth0.com/docs/universal-login/universal-vs-embedded-login
I've an ETL tool that is capable of making REST API calls against the Yammer network and retrieving data for analysis. Currently, how I make Yammer REST API calls is through an App that I've created. I then generated the authentication token and then used this token in the REST API calls to get at the data.
What I'd really like to do now is to provide an app that allows me to call the REST API (using the same ETL tool) without the person installing the app to have to go through the rigmarole of generating the auth token.
I suppose one approach could be to use some JavaScript that displayed the token to the user so that they could then pass it on to us... Do you folks have any other suggestions as to how I might do this?
There isn't a recommended way to skip the OAuth authorization, but you can automate a lot of it away. I created a Python script that uses the YamPy library to acquire a token. It even fires up the browser to the correct URL for authorization. You should be able to do something similar with other languages.
Calling the impersonation endpoint is another possibility. This will get you an OAuth token for another user so you'd need to have an app is just for producing OAuth tokens. It's probably a bit trickier to build right and secure than my script. Impersonation was designed for a specific category of app which means I don't recommend it by default. Even when it is a workable option it hides the authorization from end users which can potentially be a security issue, if say you app is compromised and handing out OAuth tokens. At least if the Yammer screen is in the way it's a bit more visible to the user what is happening.
I've been researching PASTEBIN type API's that would enable storage of code snippets for a project I'm working on. The problem is that most if the API's I've found do not support edit/update of existing pastes.
I found that the Snipt.org API does support snippet updates. However, authentication for the snipt.org API is done using your Twitter account. The snipt.org API docs (https://code.google.com/p/snipt-org/wiki/REST_API_Docs?tm=6#Authorization) suggest using a GET '/auth' call (providing a Twitter uname/password in the URL) to obtain an API token to access the API. Is it just me or does this seem like a good way to compromise your Twitter credentials?
I have used other sites that authenticate via Twitter, but I get authenticated on the Twitter site first which in turn sends a token to the authorized app.
Well, obviously this API has some serious flaws.
But if you use https, the URLs of GET requests will get encrypted along the way. (But still get logged in the cache of your browser. do clear it.)
So if you really like snipt, you could use a new twitter account created simply for the purpose of authenticating to snipt.
It won't feel particularly good. And I have some serious doubts about the rest of their security code based on this part of the API. But I do not see how exactly your credentials could be stolen using this part of it by others than the snipt maintainers who already have access to your snipts. So if you protect only snipts with the credentials, and no tweets, you should be alright.
I'm building my first REST API from scratch and am trying to understand the best way to handle API tokens. I'm not talking about "user authentication" (I would be using OAuth for that). I'm talking about public/private tokens that an application uses to identify itself so that my API can decide whether or not the application is allowed to use the API in the first place.
Some API resources will be available to anyone with valid token(s), and some will require OAuth authentication. I will be communicating with the API over HTTPS, but I still want to make sure I am following some sort of standard for passing tokens back and forth.
You actually are talking about user authentication, believe it or not.
I'm talking about public/private tokens that an application uses to
identify itself so that my API can decide whether or not the
application is allowed to use the API in the first place.
That's user authentication - it's just that the "user" is the application calling your APIs.
If OAuth isn't enough to do everything you need (and it might, you should check!), you shouldn't start adding yet another custom authentication method to HTTPS. Instead, stand on the shoulders of giants and use Basic Authentication, because that's what it's for. Your tools, sysadmins and API clients will thank you for it.