ADFS 2012 has one URL to get CODE, and with that CODE, we can call another URL to get access_token.
//get code
1. First call - POST (client_id, redirect_uri, resource, response_type = code), Body (username, password, authmethod)
2. Second call - /token
What is the best aproach when calling from mobile application?
Do I need redirect user in web view to login on server and get CODE
Create on mobile app form for username and password, and do a call in background - it returns HTML of page (parse it and get CODE)...but, currently I can't get CODE, constantly getting login error
For mobile, the nest way is to use one of the ADAL libraries.
Related
I have an existing website that I want to do a proof of concept with OAuth2 / OIDC. To this end I've configured a locally running IdentityServer4 MVC app as my demo OIDC server following the IdentityServer4 quick setup guidelines. This works fine and navigating to:
http://localhost:5000/.well-known/openid-configuration
Lets me see the discovery document.
I have created a fake login page on this OIDC app which consists of just a login button with no user credentials required.
There's no actual user database and I'm just hard coding some user details to return when the 'authentication' occurs.
In my pre-existing site I've added the OWIN middle wear and am configuring OIDC using the OpenIdConnectAuthenticationOptions. The clientId, scopes, secret etc all match as required and the authority is set to point to my locally running demo OIDC app (http://localhost:5000). The redirect url is set to return to my pre-existing site once authentication is complete.
This all appears to be fine but here's what I want to achieve and can't get working. On my pre-existing site when I navigate to any page that requires authentication I want the user to be redirected to the login page I created on OIDC app. They click the login button (no user details required) and are authenticated and redirected back to the original page.
Currently when I navigate to a protected page I am successfully redirected to the OIDC app but I am redirected to an error page and I don't know why. The error page gives me no detail, it's actually hard coded in the app.
When I look at the discovery document I see that the setting for the 'authorization_endpoint' is set to:
http://localhost:5000/connect/authorize
So I thought maybe I needed to either change that to point to Home/Login which is where I've created the dummy login form, or else I needed to actually create that connect/authorize endpoint and put my form there. Creating the end point makes no difference, it never gets hit and instead I just get the error page on my OIDC app. Changing it to home/login also appears to be ignored.
I am away from my main PC at the moment hence the lack of code snippets but essentially the set up is as per the IdentityServer4 quick setup guide and the OIDC app does appear to be working.
The issue is getting my pre-existing site to properly redirect to the login page.
I've been stuck on this for quite a while now and would like to even get to the stage of seeing the dummy login page. Any pointers are appreciated and again apologies for the lack of sample code.
UPDATE
I've got the login form appearing by setting the openidconfiguration like so:
Configuration = new OpenIdConnectConfiguration()
{
AuthorizationEndPoint = "http://localhost:5000/home/login"
}
However, this isn't logging me in when I click login. On that login action I'm doing this:
await HttpContext.SignInAsync("subjectId","username", authenticationProps);
And then redirecting back to my existing site. However it's not authenticating me and the redirect ends up being redirected back again to the login page.
UPDATE 2
I think the redirect URI should possibly be doing something more. Currently I do the following:
Try and access a restricted page -> Redirected to OIDC server -> Click Login (this sets the subject and user successfully) -> Am redirected to redirect URI which immediately bounces me back to the OIDC server.
So maybe the redirect URI is supposed to confirm login or otherwise do something?
So in the open id connect protocol, the authorize endpoint is used to validate the client information passed as query parameters (client_id, scopes, redirect_uri, etc). In your authentication server, none of that is being checked if all the endpoint does is return a form. Then again the validation can be tedious so keeping the authorize endpoint separate from the endpoint for logging in might be worth a thought.
The developers of Identity Server thought the same thing which is why they set up the endpoint (and endpoint validation) for you as part of the middleware. The validation uses the components that were injected (primarily the client_store, and your defined scopes) to be used by Identity Server.
After the framework validates your authorize request using your client store implementation, it will redirect the user to whichever login page you specify. The login page can be specified by changing it with the a delegate that can be passed in as the second parameter of 'AddIdentityServer' (that takes in something of type IdentityServerOptions that we'll refer to as just 'options'). In the delegate you can specify the login url of the page by changing the value of 'options.UserInteraction.LoginUrl' to the url of the login page.
After the user logs in and you call the signInAsync method on the HttpContext, you're actually supposed to redirect back to a query parameter passed to the login page referred to as the 'return_url' (which is basically the initial authorize endpoint request). This authorize endpoint further validates the cookie and will send the user back to the 'redirect_uri' (if consent on the client is set to false) with a code (if using the authorization code flow) or the id_token and optionally the access token (if using the implicit flow).
Assuming the implicit flow for simplicity, the tokens can be found in the request to the 'redirect_uri' and from there it's all up to you. Commonly the client will issue some kind of cookie (which can potentially contain the id or access token) to mark the successful authentication by the identity provider.
I am developing an API. I implemented register, login, and Facebook auth using Auth0.
My token expires after one day, and I need to get my refresh token to sign in the user again without requiring its credentials again. I have to make a call to /authorize with these parametrs [sic]:
GET https://YOUR_AUTH0_DOMAIN/authorize?
audience=API_IDENTIFIER&
scope=SCOPE&
response_type=code&
client_id=YOUR_CLIENT_ID&
redirect_uri=https://YOUR_APP/callback&
state=STATE
but I get this error Image
The GET response should give me a code, which I would use to get my refresh token making another GET request on /oauth/token like that: Image
Does anyone have any idea how to get over the first step?
Have you tried using curl to get access token and refresh token and then refresh outside of your app? The following link has very detailed instruction on how to do that with auth0.
https://auth0.com/learn/refresh-tokens/
I don't have great experience with authentication, for the moment I've created a simple MVC application with basic authentication(MVC creates all of it when you select Individual User Accounts). It works good, I've configured it globally so the app forces the user to be authenticated in order to access to anything, it works good, you can Register and then you can Login using the registered username and password. The thing is that I'm trying to make some requests using Postman and I get a 200 OK Status but I'm getting always the Login page and I'm never getting the json data I want to... even if I'm selecting Basic Authentication in Postman and entering the username and password already registered...
Is it possible authenticate with postman, make a request and get json data that I am returning from one controller?
I'm having a good time with Satellizer, except in one case - the Twitter oAuth 1.0a flow. The popup does not close after successfully authenticating a user.
My configuration is;
$authProvider.twitter({
url: '<my server endpoint to get request token (POST)>',
redirectUri: '<my server endpoint to perform oAuth login (GET)>'
});
I have set the callback URI for my Twitter app to be the same as redirectUri (and I also pass it when getting a request token from Twitter).
The flow that I see is this (basically, I get to Step 10 in the oAuth 1.0 flow and then the popup does not close):
User clicks the "Sign in with Twitter" button
The popup appears and an empty POST call is made - my server returns the request token
The user clicks "Authorize Application"
My server receives a GET request for the oAuth login (not a POST as the documentation says I should)
My server correctly authenticates and returns the Bearer token.
And then nothing - it all stops. I suspect because I am responding to a GET not a POST but I can't figure out what is causing the GET.
Any help would be greatly appreciated!
Ben
Apologies everyone - this is my fault. Per my comment above, once I set the redirectUri properly and used just the /auth/provider method it all worked.
Quite simply, on the second call the parameters come through (correctly) in the body. Once I realised that, extracted them, authenticated, and then returned, it all worked like a charm.
I want to simulate several function in my rails application by using curl in terminal. The problem I am facing now is that first I login in my application using user name and password. But then while I am hitting the url corresponding to a function of a controller, it is giving message "You are redirected to sign_in page".
I think I have to use authenticity token somehow. But I don't know how to get it and how to pass it during each call to controller function. So if anyone helps me to figure it out, I will be really grateful.
You can check the format of the request modify the controller code to handle both the html and json request separately.
In the first request get the access token in response from your controller. You can use this authentication token for your further request.
In order you generate the access token
Create a migration in users table for authentication token
When the user logins/sign-up create the authentication token for that user
Once you make these changes you can have the user information passed using the curl request and pass back the authentication token in response for the user.
For further request use this authentication token to verify the user and perform the actions.