I am very new to IdentityServer and Open ID Connect and most of what I know comes through the three walk throughs in the Overview section of the IdentityServer3 documentation. All of those samples demonstrate how to use the Authorize attribute to secure a controller action, which results in a redirect to the IdentityServer-hosted login page. What is the typical or recommended way to provide a Login link in the client application? Could my client application have it's own login page and then call IdentityServer to validate the login and provide a token? If so, is there a sample that shows this? If not, is there a way to have the login link in my application bring up the IdentityServer login page? Is it as simple as securing the Login action with an Authorize attribute?
I don't think it is right that client has its own login page. Imagine you use Facebook as identity provider, and would you expect facebook users to enter their Facebook crediential on your login page?
One method is what you described using server side challenge redirect, or configure your app as a Javascript implicit client - see example , which it builds up authroize challenge URL. Either way user sees login page from identity server.
Related
I will try to keep the question as clear and direct as possible.
Social authentication (Facebook) configured with Okta with redirect URI as URL to my custom webapp. This custom webapp relies on Okta for authentication.
User visits my custom webapp (unauthenticated) and clicks on the social authentication URL to login to my custom webapp.
User follows the normal flow, gets authenticated by facebook and thereby by Okta (as per usual flow) and is then redirected by Okta back to the custom webapp.
The entire flow is successful and the user can see an Okta session cookie set in their browser.
Custom webapp now needs to show the user their own profile by making an Okta API call.
Problem: How can my custom webapp identify who just logged in so that they can fetch their Okta profile using API?
I am aware that Okta knows who just logged in due to claims that facebook sends to the OAuth client (Okta), but how will my app know the identity of the user who logged in?
Thanks,
Jatin
It depends on the OAuth2 flow you've chosen for your app, but the end state is getting an id_token from Okta which contains claims about the user that just logged in.
If you've set response_type=code in your social auth url (/authorize), after Step 4 you'll get a code query param in the redirect that you can then exchange for the id_token using the /token endpoint.
Or, if you've set response_type=id_token, you should already have the id_token in the redirect - you just need to validate/decode it (more info here).
I have a Workflow application(website) using canjs. The various steps(pages) are preloaded. A user is allowed to explore the app without login. However if the user wishes to save the workflow, they must login. Alternatively the user can login at any of the steps in the workflow.
The application has a provision for users to login using Facebook and Twitter.
The backend consists of Laravel and Socialitelinkpackage take care of the login process.
As Facebook and Twitter use OAUTH the login work flow is as follows :
Client calls a login init route.
The route redirects to a login page of the social login provider(FB or twitter)
User Authenticates/Authorises your app
The user is redirected to a success route (say /success_callback) on your app. At this point we can use Socialite package to get the user information.
The issue I'm facing is that I don't want to reload the APP on the client browser. So how to inform the client from /success_callback if the user has logged in or not, etc.
I am creating a SaaS that will allow users to interact with it via their web applications. I would like to create a CAS type login mimicking Facebook connect so when you click the 'Login' button on the users website it will popup a window for you to login with my SaaS credentials.
I do not want the SaaS users site to be able to access the users login credentials so this is why I thought of CAS. However, it doesn't look like Facebook Connect redirects to the CAS server. It looks like they just popup a window to the facebook login then create a cookie once the user successfully logs into facebook. How then does the Facebook Connected site access that cookie?
I am wanting to basically be able to keep the end user on the current website without being redirected to my login application. I would like to mimic what facebook does with just popping up a little window and have them login then refresh the page after they login but I am not sure how to go about this.
Any ideas?
Facebook uses a third party cookie: they set a cookie on your domain that you can access to get the necessary credentials.
EDIT: the easiest example would be to look at PHP's setcookie function. Notice that there is a domain parameter. If you change the domain to match the domain of the actual website that initiated the authentication action then you'll be able to set a third-party cookie.
Note that on IE there are certain headers the domain that initiated the authentication action needs to set to allow your third-party cookie to be set. See http://www.spamcollect.com/archives/33 for a short writeup of how that works.
If you are working in a different language you'll need to use whatever cookie management functions they offer.
Another option may be to do this with CAS programmatically using the REST client.
https://wiki.jasig.org/display/CASUM/RESTful+API
In this way you could take the users details and login to CAS without being redirected.
Facebook uses Cross Domain communication which is what I will be using.
I want to allow users connect to my website using their facebook account.
First, the user authorizes my application and then I get an access token. Problem is, that I'm supposed on the first time to register the user, and the next time to auto login him based on his facebook email.
How do I create a SECURE way to auto login the user?
I'm using pure javascript, but I can't find any way to create a secure mechanism.
Thanks.
Facebook should handle all that for you - when they come back to your website, they can click the 'login' button(javascript SDK) and facebook should pass you back an access token.
I may, however, have misunderstood the question.
I'm curious how these systems work technologically. As I understand it you do the following as a user:
Go to your favorite 3rd party site.
Click the "Facebook Connect" button.
Log into Facebook (if not already).
Authorize Application
You are routed back to the 3rd party site logged in.
But, how does the 3rd party site talk to FB about who you are? I can understand how it could get the information it needs when you initially authorize the application, but how would it know afterwards? Here's a scenario:
You go to Facebook and log in.
You then go to your favorite 3rd party site (which you already authorized).
It already knows you are logged in!
A background ping using an IFrame is performed, and if the currently signed in account has already authorized the application, then the access token and user id are returned to the application. With this the application can decide what to do (usually, set a cookie and refresh the page so that the server can re-render the page knowing who you are based on the cookie that was just set). If you're curious, you can look at the Facebook implementation of the client side JS method called FB.getLoginStatus() here: http://github.com/facebook/connect-js/blob/master/src/core/auth.js#L117
It's using a 3-legged authentication system called OAuth.
After you start the process, the 3rd party site connects to Facebook, and if you were already logged into Facebook (live session with cookies) then it will just use that, and ask permission to authorize the 3rd party app.
Once it is authorized, it will get an auth_token, which it can use to access information from your account, unless you revoke it's access.
Check out OpenID. Also this presentation is very interresting: Facebook Connect vs FriendConnect
It all happens through OAuth2 mechanism ,where the third party application already registers with the facebook(or any other website which has oAuth2 implementation) and gets the Id(usually termed as clientId) and secretCode(i.e., clientSecret).
So, when you want to login into the third part app through fb, the service provides (clientId+clientSecret+callbackUrl )---> to facebook.while , the first two were to authorize the third part service and callback URl is URL where facebook responds back with a "accessToken" for that account.
Using this accessToken , the third part service will invoke facebook's graph api's to get the user related info and use them to login the user into their service.