I was wondering if there is a easy way to implement a authentication with custom fields. For ex: My app generate a code that is sent by SMS and I want to authenticate the user with this code. So I can’t use strategy local or anything.
I was thinking about create another service that when the code is received it check the database and generate a JWT token and return to the client app. But how to set that token to the app so it will use in the nexts rest and socket calls?
Any clues?
If you know the user prior to the generation of code then you can do it via local strategy by saving the generatrd code to that user and use it for authentication. You can also make use of the authentication service hooks. Or in the verifier.
See it here. https://docs.feathersjs.com/api/authentication/local.html#local-authentication
In addition to the local auth feathersjs provides, there is an additional library supporting all kinds of confirmation procedures, password reset, etc. It is only referenced in the API part of the docs somehow. Here it is.
Related
I have a NextJS web app and I'm adding firebase authentication to it.
I want to make secure GET calls to my server, and was wondering what is the token I should use with the server and where to set it?
Should I use the firebase user's AccessToken?
And should I send it in the URL query parameter (or header)? Aren't both alternatives exposed to whomever sees the URL and they can impersonate the user?
Thank you in advance for the help.
Are you talking about your API keys? if you are they are supposed to be visible, you need to write Security Rules which are pretty simple to use.
Read more here: Learn about using and managing API keys for Firebase
If you want your own server-side code to use the caller's Firebase Authentication credentials to ensure they are authorized for the operation they are trying to perform, you should:
Pass the users ID token from the client to your server over a secure connection. This is typically done in the Authorization header of the HTTP request.
On the server decode the ID token, and then check your own authorization logic to see if the call is allowed.
The entire process is quite well described in the Firebase documentation on verifying ID tokens, so I recommend checking that out too.
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'm trying to call an Azure API App configured with Azure AD authentication. Assume for the purposes of this question I cannot use the Azure SDK and need to write code to get a token and insert it into the API request.*
I have established that there are two modes - 'client flow' and 'server flow', where client flow entails following at least one redirect to an issuer to get a token, and server flow where the server does this for you. Since I'm talking about doing this in code, following redirects would be possible but fiddly, so I'd prefer to use a mode where the URI or URIs to visit are known ahead of time and return content, rather than redirecting. The following diagram illustrates how the gateway routes all requests.
I think the mode I need is client flow, which would go something like:
Get an access token from the identity provider (which is what? how do I find out where this resides? what is the format of the request I have to send to the IdP?)
Pass the access token to the gateway (in what format?)
Receive another token in the gateway response
Supply this token in a header when making an API request (which header?)
How am I supposed to do this? The Azure documentation doesn't give enough detail about how it works, and expects all users to just use the SDK, which hides what is actually happening.
The actual reason is that ultimately this will need to be called from BizTalk, which uses the WCF WebHttpBinding to call restful services. I'm writing a custom behaviour to insert a token header into the request, but I need to know how this token should be acquired. It's possible to run arbitrary code in BizTalk but trying to do this makes the solution complicated, and config-only or mostly-config with minimal, loosely-coupled code is the simpler solution
Just want to understand your scenario better, Because you are going to use it from BizTalk Receive Pipeline, The scenario can be simplified by enabling a customer authentication token right ? Basic username and password for your API you have hosted on the cloud. Does BizTalk want to authenticate it self with tokens for each AD User ?
To answer some of your questions
Get an access token from the identity provider (which is what? how do I find out where this resides? what is the format of the request I have to send to the IdP?)
After you have configured your AD configuration, Once you have completed the authentication, I am assuming your are using ASP.Net here, You can find everything you need about the claims on your Thread.CurrentPrincipal, You can convert it to ClaimsPrincipal like so var claimsPrincipal = Thread.CurrentPrincipal as ClaimsPrincipal; and then you will find a lot of good information on this object. Name of the user logged in, list of claims the principal has etc. I have not explored every avenue here, but this should be a good starting point.
Your API App is running on this process which means you have access to these claims in your API App code as well.
I would build a custom pipeline in BizTalk that uses Azure SDK to authenciate and build this scenario, it is a bit complicated but it will give you more control over what goes through the pipeline as well when authentication fails with permission issues and so on.
I started new project. It is small application (playground) to learn couple new concepts. I will create backend API using Ruby on Rails and Single Page Application using React. I stuck in Authentication. I would like to create custom Token-based Authorization/Authorization. I came to following auth flow:
User fill password/login and send to backed using Ajax and through secured HTTPS connection.
Backed checks if user exist in DB. If user exist backend create Token and save to Redis with user id.
Backend response with token to client app.
On client side I will save above token to local storage.
Before every request I will get token from locale storage and pass to request header.
On backend I will take token from header and check if exist in Redis db.
Is this flow correct? Should I decrypt token on client side or It is not necessary? This project is only playground but I would like to do It properly. Please give me some comments if above flow isn't good enough.
I think that you have the right approach. This link could give you more details about token-based authentication:
Implementing authentication with tokens for RESTful applications - https://templth.wordpress.com/2015/01/05/implementing-authentication-with-tokens-for-restful-applications/
Hope it helps you,
Thierry
I am creating a small REST service. I am looking for different authentication methods.
For sites I used the module Flask-Login. It seems the session authentication. The module Flask-HttpAuth provides the http and digest authentication methods. I am little bit confused.
Do they complement each other?
What is better to use for what is a reason?
Thank you.
For a REST service you do not need Flask-Login. Typically in web services you do not store client state (what Flask-Login does), instead you authenticate each and every request. Flask-HTTPAuth does this for you.
You would use both only if you have an application that has a web component and a REST API component. In that case Flask-Login will handle the web app routes, and Flask-HTTPAuth will handle the API routes.
Disclaimer: I'm the author of Flask-HTTPAuth.
You can setup Basic Auth for Flask in a very simple way, without further modules, using decorators.
Take a look at: http://flask.pocoo.org/snippets/8/.
With flask-restful, just add method_decorators = [required_auth] to the Resource class attributes.
You can extend the snippet above, to allow for example user retrieval from a database.
Note that in a REST architecture, requests are stateless: you don't use sessions, but send identification tokens along with every request (see http://broadcast.oreilly.com/2009/12/principles-for-standardized-rest-authentication.html).
Yes they complement each other.
You can also take a look at Flask-security, an all-in-one lib:
https://pythonhosted.org/Flask-Security/
Session based authentication
Role management
Password encryption
Basic HTTP authentication
Token based authentication
Token based account activation (optional)
Token based password recovery / resetting (optional)
User registration (optional)
Login tracking (optional)
JSON/Ajax Support