I would like to know if there exists alternative for OpenID/Oauth2.0 for first-party apps like public SPA without redirecting user to OpenID login page?
I know there exists password grant type, but it's deprecated as written in Oauth2.0 docs.
And if there is no alterative solution, is it good choice to implement only JWT issuer(auth) service without OpenID on my own? Will it be still secure? If yes, then which details should I take into consideration?
If you have a first-party app, which only talks to your backend then it should be enough to use sessions. You don't need to implement OAuth and JWTs, and using sessions will solve some you some security issues with tokens (e.g. how to securely store them in the browser).
If you do decide to use access tokens I highly recommend implementing OAuth or OIDC, as this will mitigate some common security vulnerabilities.
Related
I have two web applications app.domain1.com which is a SPA with his own API on api.domain1.com and app.domain2.com) with each have their own authentication system and user accounts
and I need to authenticate the user from app.domain1.com from app.domain2.com. The goal is to simplify switching from one app to another without requiring the user to log into each application by re-entering their password. I'm the owner of one app only so It's not possible to put them behind a reverse proxy or so.
Example :
app.domain2.com redirect to app.domain1.com/connect/{JWT} -> app.domain1.com SPA extract the JWT and send it via ajax to api.domain1.com for validation and login.
I have looking for OAuth2 and OpenID Connect for these but OAuth2 is more about delegation of resource access than authentication and OpenID Connect needs an Identity Provider which seems incompatible with my use case where each app has his own authentication mecanism and where I could not add a central authentication server.
Ideally, I'd like to adhere to a standard protocol.
I thought I could expose an endpoint GET /connect/{JWT} on each app.
The JWT could contains an email which could identify the user account, app.domain1.com and app.domain2.com could then share the secret for validating the JWT has not be tampered
and could have a short validity duration.
This endpoint validate the JWT, verify if a user match the email inside the JWT and log the user in.
I'm not sure about the security considerations with these process and if there is any other options ?
Thx for your help.
In my opinion you should go with OIDC. That protocol is designed exactly for the feature you described here. You can have one of the apps act as the IdP, and the other will be a Relying Party. It depends on which technology you use for your apps, but in some languages there are libraries which will turn your app into an IdP.
You can think of some generic protocol to make that federated login work, but you will be better off using standards. This way you won't have to wonder what are the security implications for your solution - you have security considerations for OIDC described in the spec itself.
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
Ok, Having read so many QAs here about OpenId and OAuth (like this, I hope I understand the difference between both. I see people recommending OpenIDs for authentication (proving identity) and OAuth for authorization (say tweet or post something to fb wall,etc).
But my question is- how about using Facebook/Twitter OAuth for authentication to a website? like the way SO itself uses Facebook login as an identity of a user. I'd like to hear what is others opinion about using something meant to authorize to use to authenticate. The reason why one might want to do is the same as using Open Id i.e., to ease the registration process for a new user.
PS: Please correct me if I'm still confusing the use of OpenID/OAuth.
You are not confusing anything as far as I can see. OpenID is indeed a specification for identity authentication, and oAuth is indeed mostly aimed at solving authorization problems.
That having been said. You CAN use oAuth for identity authentication as well. There is nothing to stop you from doing that. I for one will definitely leverage that.
There only drawback of using oAuth for identity authentication is that you may want providers to be strict with what their access tokens allow you to do. What I mean is, when you authenticate a twitter user, you will also be able to do everything else that the Twitter API allows you to do (which is basically everything). Facebook is potentially more restrictive and authenticating applications can be granted only a subset of API functionality.
OpenID does identification, and that's pretty much it, I love it. But I'll gladly use oAuth for the same purpose any day of the week.
Should I use oAuth, for example LinkedIn or Twitter, as my signin mechanism for my app? It seems that most apps just use oAuth to connect other services to it, but they make you set up your own user/password after you use oAuth (including StackOverflow), and I'm not really sure why this is. Would love some insight here. Thank you.
Why not use OpenId, to allow people to sign into your application, without having to type any specific login/password ?
Quoting the corresponding wikipedia entry :
OpenID is an open, decentralized
standard for authenticating users
which can be used for access control,
allowing users to log on to different
services with the same digital
identity where these services trust
the authentication body. OpenID
replaces the common log on process
that uses a login-name and a password,
...
BTW, that's exactly how one logs-in on stackoverflow ;-)
OAuth purpose is not authenticating your users with your site, is letting your users allow you (the oauth consumer) access to their protected resources in other sites (oauth providers) like LinkedIn, Twitter, Google APIs etc.
For authentication, you should use OpenId as others have pointed
Twitter provides a Sign in with Twitter flow that is OAuth but provides a faster redirect if it is an existing user of your service and they are already authenticated with Twitter.
http://apiwiki.twitter.com/Sign-in-with-Twitter
If you are building a Twitter centric application this makes a lot of since to use and you won't have to implement an entire alternate authentication method like OpenID.
Be careful if you let users authenticate with both Twitter and LinkedIn as users will inadvertently create two accounts and need them to be merged.
Facebook and Twitter both have the "Login with Facebook/Twitter" APIs to actually allow users to login without having to create an account for your website. Both of them will return you a valid session that may (or may not) expire. So you actually wouldn't have to ask users to decide on a username/password, as you can fetch both from the APIs (you can not get the users email address when using Twitter though)
So why add those functions to your website?
Users are in general more likely to hit the "Login with ..." button than going through the whole mail address authorization process and entering their name, etc...
Linkedin only has OAuth for usage to its API. It will also depend on what type of language you are writing your webapp in, they should have premade wrapper libraries you could tap on to.
Most Oauth implementations require the user to login with the originating site in the process.
An example is: http://code.google.com/apis/accounts/images/OAuthDiagram.png
What if I want to use my own account to access a generic feature, such as a search for people outside of my network, and don't want them to login? Is there any way to login with my own generic account?
I am creating a web service that interacts with many social networks by searching them, so by forcing the user to login several times to each network if I want to use their API is just bad user experience.
You could try to authenticate your account manually and then store the access token. Any subsequent request would be made with the stored access token.
There are several problems with this approach:
if the token expires, you have to reauthenticate
you might run into request quotas if you do all requests from one account (e.g. Twitter)
If possible, I would use something like HTTP basic auth to authenticate to the services.
When you are strictly speaking of OAuth, it is not meant for this scenario. Try looking into SSO (Single Sign-On).
OAuth can also be implemented in conjunction with SSO solutions.