I want to implement OAuth/OpenID for Website One and use it in Website Two.
I create Sign Up, Sign In, Sign Out, Profile functionality/Pages for Website One and want to use authentication in Website Two like Facebook or Twitter authentication.
As an additional information if you got interest you can visit trial websites of Website One and Website Two. Please do not expect full or correct functionality because as I said above they are just trials yet.
P.S.
I decided to use OAuth. Forget about OpenID.
I had a look at your sites. It's not working this way.
You want STOZE to use the authentication from TIKSN? Well, you have to configure STOZE as an "oAuth resource server", so it keeps the protected resources, and configured to work only with token he gets from TIKSN, which will be configured as an "oAuth identity provider".
Read a little bit about oAuth...
OpenID is a different story - then, you will have to configure TIKSN as "OpenID provider", and configure STOZE to enable it to work with OpenID providers (so TIKSN will be one of them, but you will be able to use also Google, Yahoo, etc)
Read a little bit about OpenID...
HTH
Related
I'm having trouble understanding how ASP.NET Core authentication works.
I want to implement JWT access token authentication with refresh tokens. To my knowledge, this is the industry standard for authenticating a client (Mobile app, SPA Web application). For security purposes, I'd prefer to not implement my own authorization logic including JWT generation and refresh token handling. Since ASP.Net does not natively support this, Naturally my choice would be to use IdentityServer4, a large open source library for handling this kind of stuff.
However IdentityServer4 is heavily based on OAuth, and I'm not sure how that works with SPA applications and mobile apps (clients I trust). It requires the client to redirect to some arbitrary webpage to enter their credentials and then redirect back to the app. Gross. I've never seen a major app like Snapchat, Instagram, etc. have this kind of authentication flow where you are directed to some webpage/browser during the login flow. Luckily IdentityServer4 has a little feature to handle username/password authentication for my trusted clients (http://docs.identityserver.io/en/latest/quickstarts/2_resource_owner_passwords.html)
Great, that seems to suit my needs. But... Now I want to add Facebook Authentication. IdentityServer4 allows for External Authentication, however it is still cookie based (to my knowledge). Which requires the Android/iOS/SPA app to redirect to a webpage and then redirect back to the app. Again, this isn't ideal from a user perspective. Facebook provides native mobile SDKs to handle this type of authentication which returns an access token so there is no need to redirect to web pages using cookies.
Now lets say my iOS app uses the Facebook SDK to grab an access token for the user and sends it to the backend. The backend validates the token against the Facebook SDK, and subsequently registers a local user in it's own database.
Now when that same iOS user tries to login to the app, the app will generate a facebook access token for that user from the SDK and send it to the backend. However I'm not sure how to utilize IdentityServer4 to generate a JWT for the user since I need that users' username and password. This is where I'm stuck. I seem to be fighting against the library which makes me believe I am severely misunderstanding something.
TLDR; IdentityServer4 seems to be heavily based on cookies which doesn't really fit nicely into mobile apps/SPA webpages when you are redirected back and forth from authentication webpages. Am I using the wrong tool for the job? What are some alternative solutions?
As a note on big social apps: I think it comes down to who keeps the passwords. Facebook, Instagram, Snapchat, Google act as identity providers to third parties. They themselves require user to register and specify the password which they keep. Therefore they can use any customized approach for handling validation with those passwords. However, if any of them offerred a posibiltty to log-in with the other I.e Instagram were allowing to sign-in with Amazon credentials, then they would need to follow through a standard way like OAuth and redirect to the third party for log-in. Last time I checked Instagram, Facebook and Snapchat only offer to register and no option to sign in with 3rd parties which explains why the don't need redirects.
Now if we establish that a redirect is a necessary evil, then the means to carry over the data accross aren't that numerous. I.e. we either would need to pass data via a query string or use cookies. Am I missing any others?
Both have limitations but since cookies are persisted and browser carries them automatically with each request, they do seem like a better option for the job, especially if multiple redirects are required for an external IdP to track the state of authentication request. The same reason is mentioned here:
http://docs.identityserver.io/en/latest/topics/signin_external_providers.html
It's absolutely the right tool for the job if you want what OpenID Connect and OAuth2 give you. It sounds like you may need convincing though and it may be that your use case doesn't need the full breadth of functionality offered.
If you have multiple client applications and APIs in play then I think using OpenID Connect and IdentityServer4 the right choice at this point in time.
Regarding native apps, you used to word "gross" to describe using the user's default browser to perform the sign in process and it's understandable why you might think that at first but it's not as bad of a UX as you'd think and has plenty of advantages:
The client application is completely decoupled from how authentication is actually done be that federation, social sign in (Facebook in your case), multi-factor, retina scan etc. Your identity server deals with all that complexity and is a single point of management (and failure - so make it highly available!)
Single sign on is possible - if they're already signed into your IDP then they can go straight in (although you have full control of the flow - want them to consent or confirm the sign in request every time - you can do that)
If the user has a password manager set up in their browser then that'll work too
Both iOS and Android offer APIs for doing this stuff and the work well. If you skin your native and web UIs to look similar the flow from a user's PoV is not jarring at all.
You can still use refresh tokens (ultimately secured by the platform) so you don't actually have to do the interactive flow very often anyway.
Some additional reading below. Quite a lot of thinking has gone into this from the industry so it's definitely worth digesting the current best practice.
https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html
IETF current best practice: https://www.rfc-editor.org/rfc/rfc8252
Don't make Scott hate you ;) : https://www.scottbrady91.com/OAuth/Why-the-Resource-Owner-Password-Credentials-Grant-Type-is-not-Authentication-nor-Suitable-for-Modern-Applications
For client side SPA browser apps OIDC provides the implicit grant type and uses a silent refresh and IDP session monitoring mechanism to maintain the session. Check out the oidc-client-js library which implements this approach.
I am trying to develop a non-web application (mobile, non-mobile) for consuming information from Foursquare.
I would like to have the user authenticated by entering a valid username and password and accessing his account using this authentication.
Is this possible? From what I've read, it seems the only way to access Foursquare is by using OAuth, which is not what I had in mind.
Any thoughts?
Thanks!
RP
OAuth isn't a protocol that works only with webbrowsers. However, many OAuth services provide a web-only authorization endpoint. Once the authorization part is done, you can use OAuth from any application, web, desktop or mobile (and embedded systems).
There are many ways to handle this browser requirement, but these two are very common:
Simply embed a webbrowser in your application that shows the user the authorization page, let him log in, and finish the OAuth sequence. Once that's done, you have the keys and don't need the browser anymore.
Use an external browser. This is definitely the recommended approach, since it's more secure and users will probably like it a little bit more. The idea is that you simply open the authorization URL using the user's webbrowser, and set a redirect URL that points back at the app. This is normally done using a myapp://auth URL, which will simply send the data to the application again.
I believe OAuth is your only option if you plan on using the Foursquare api. You can read about Foursquare's Authorization here https://developer.foursquare.com/overview/auth
I want to use google/yahoo ids to be used to login to my website.
As its done in stackoverflow.
Can any one provide me a starting point.
That authentication method is called OpenID. You can get details at the open id website.
If your webiste uses PHP on the server, here's a resource to get you started with OpenID and PHP
UPDATE
Since I've posted this, the world of open federated authentication has evolved quite a bit. If you're interested in this you may wish to look up OAuth v2 online, or check out these links: www.oauth.net and the Google resources on OAuth2 available here.
OAuth builds upon the concepts of OpenID and it expands the functionality quite a bit, in particular in the areas of not just providing authentication but also providing authorization for applications using a centralized provider of the user's choice (i.e. Google, Facebook, Twitter or your own :) )
I have been using JanRain for the same thing. It is free and integrates with loads of different login providers, such as, Facebook, Twitter, Google, OpenId (generally), yahoo, msn, and many more.
There is code that lets you integrate it with almost any programming language/platform you want.
try this sample in CodeProject.
http://www.codeproject.com/KB/web-security/OpenIdFormsAuth.aspx
It worked fine with me.
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.
I recently was tasked to implement Single Sign In functionality where users could register and sign in to this site using their credentials from a more popular site. That got me to start looking and asking around as to who was doing Single Sign In. I was surprised to learn how much of a hot button topic it turned out to be.
If you have rolled out Single Sign In for a web application, then which authentication providers did you end up using and why?
Try OpenID, stackoverflow uses it as well.
OpenID is very good if its an internet application. Lets users use things like their google account to log into yours.
If it is an intranet application then Windows Auth is fairly common but it works best with IE.