I have a Web API 2 with bearer token authentication, where an external site authenticates in my api and makes requests by sending the token in the request header, but I also have a MVC 5 Web Site, where authentication should be automatic in this site, the Web API will have a method that redirects to this Web Site and it should already open authenticated, this web site will have just one client, the web api, and the users came authenticated from web api.
How could I authenticate the web site automatically?
I thought in two different ways to solve this problem:
Use authentication cookies, where I perform a redirect from the web api to the site passing the login information (placed in the web.config, with user and password, or a kind of key), and then, the web site perform the authentication and set a cookie for the browser.
Use bearer authentication in both web api and web site (With the same Machine Key on web.config), and when the web api redirect to the web site it pass the bearer token generated for the client, but when the user navigate on the web site, I need to pass this token in the header all the time, and i think that is not a good idea share this token between the web api and the web site, when the navigation ends the process needs to come back to the web api, and will have to authenticate agaIn or pass the same token to the web api.
Which of these approaches would be the most correct? Or there are some other approach to solve this problem?
I'd take option 2, you could use a token auth with the claims you need to identify that the incoming request comes from your API. It's stateless, simple and you don't need to pass sensible data among urls
Related
Im trying to implement IdentityServer authorization and my scenario is below:
we have one home page for all our application "www.vision2025.com" and i have link to my mvc application "MarketingDashboard" where users are authenticated by home page and redirect to my mvc application using windows authentication. Now user can do any action in my dashboard which interact to web API.
Now i need to implemented IdentityServer to authorize all the web API call from my dashboard but no need of login.
Please suggest any idea
Thanks in Advance
I think you don't want to build IdentityServer because your enterprise company has already built ADFS (Active Directory Federation Services). You just want to ask who maintain AD and ask him to enable ADFS for OAuth2. This is a page to help you catch all scenarios here.
Because I don't know how far you can change for all applications but there are some solutions with ADFS you can go with:
Let your main server (acts as Home Page and where user redirects to ADFS to sign in) performs On-behalf-Of flow. In this scenario, your main server will be a linked server that transfer its taken access token which retrieved from ADFS. I strongly recommend this way because you just want to add as many as your new upcoming web and api. The cons are they require you ensure protect highly access token in your main server
Because OAuth 2.0 doesn't support chaining Resource Servers yet (such as you signed in Resource Server A, then use provided access_token to call Resource Server B in different clients), you need to allow your main server store his username/password (also knew as trusted back end server , means your enterprise allows this server can store client credentials). So each time you redirect user to target MVC Application, you should transfer encrypted username/password as well. Then your target MVC application can perform Authorized Flow or Implicit flow itself in Back-end code, then returned new access token to client web to perform calling Web API.
I'm struggling theese days on the possible way to configure an Authentication + authorization system to consume a REST API from a mobile application.
Scenario:
We've developed 3 independent portals for a big customer that serves several users.
To enable a SSO for the 3 portals we've implemented a SAML authentication system using SimpleSAMLphp.
Every portal has a service provider and they make assertion requests against a central IdP.
The IdP checks username and password against a database where passwords are hashed and stored during registration.
After the login, the authorization on the portals is handled by the session on the server, and so far everything was fine.
Now the customer asked us to develop a mobile application that will require the users to login and access several of their protected resources collected during the usage of the 3 portals.
We've decided to develop a frontend application using ionic that will consume a REST API made in node.js that will serve all the data (both protected and unprotected resources).
Now here comes the question: to authorize access to protected resources on the Api we'd like to use JWT to easily achieve a stateless system.
The doubt is how to perform the authentication? We've the opportunity to check the credentials directly against the database skipping the SAML process, otherwise we've to implement a solution where the SSO IdP acts as authentication provider and then when an attempt is successful the API app will get the response from the idp and then issue a signed jwt to the consumer client. Is this second way a common implementation? Is it possible?
What path do you suggest to follow? The first could be very easy to achieve, but since we're using html+js for the app's frontend, if we decide to use the second solution probably in the near future we could recycle some code from the app to modernize some functions on the web portals, maintaining the jwt pattern and consuming the new Api also on the web.
I believe that in this case will be easier to ask a token to the new api using someway the logged in user's data already in the session of the portal. Sounds possible?
I hope that everything was clear, any help will be appreciated!
Thanks
The key goal here is to code your apps in the best way, via
the latest security standards (OAuth 2.0 and Open Id Connect).
SAML is an outdated protocol that is not web / mobile / API friendly, and does not fit with modern coding models.
Sounds like you want to do OAuth but you do not have an OAuth Authorization Server, which is a key part of the solution. If you could migrate to one you would have the best future options for your apps.
OPTION 1
Use the most standard and simple option - but users have to login with a new login screen + credentials:
Mobile or Web UI uses Authorization Flow (PKCE) and redirects to an Authorization Server to sign the user in
Mobile or Web UI receives an access token after login that can be sent to the API
Access token format is most commonly a JWT that the API can validate and identify the user from
The API is not involved in the login or token issuing processes
OPTION 2
Extend option 1 to federate to your SAML Identity Provider - enables users to login in the existing way:
The Authorization Server is configured to trust your SAML based identity provider and to redirect to it during logins
The SAML idp presents a login screen and then posts a SAML token to the Authorization Server
The Authorization Server issues OAuth based tokens based on the SAML token details
OPTION 3
Use a bridging solution (not really recommended but sometimes worth considering if you have no proper authorization server - at least it gets your apps using OAuth tokens):
Mobile or Web UI uses Resource Owner Password Grant and sends credentials to a new OAuth endpoint that you develop
OAuth endpoint provides a /oauth/token endpoint to receive the request
OAuth endpoint checks the credentials against the database - or translates to a SAML request that is forwarded to the IDP
OAuth endpoint does its own issuing of JWT access tokens via a third party library (if credentials are valid)
Web or Mobile UI sends JWT access token to API
API validates received JWT access token
I am quite new to Asp.net core identity and Identity Server 4. I am following online training course on implementing Authentication using Open Id Connect with asp.net core and Identity server 4.
If I further illustrate my solutions having Asp.net core mvc web application as client. Another asp.net core mvc web app as IDP (Identity Server4) and another asp.net core mvc web api as resource server.
For un-authenticated Users Login page on IDP is appearing. Problem for me is how does client web (asp.net core web app) knows user is not authenticated? My guess is when user first time access web app access token is not presenting on authorization header so authentication middleware knows this is not authentication request and redirect request to IDP Is it correct?
Then user redirect to Logic view of Account Controller how that redirection configured on IDP (I mean here is how exactly redirect to Account controller login page)?
Furthermore what is purpose of RedirectUris(https://localhost:44326/signin-oidc) configure on IDP. and how it works
By the way in here I am using Authorization Code flow and IdentityServer4.Quickstart.UI AccountController comes from there.
Either you know what api needs authentication, therefore, if you don't have this token available anywhere, you shall redirect the user to the oauth server. Once this one redirects back on your application, you will find the token in the url (a parameter of it if my memory is good). This token will have to be saved in memory for later usage or in your application db (standard browser feature). Then you can make a call to the api using this token that you stored.
If you don't know what api needs authentication or if your token is expired, you make the call to the api anyway, and then you get an 403 error (not authorized). Any 403 error should make the client application decide to redirect the user on the authentication portal to get an new token.
As you use code flow, I suppose you must develop a react, angular or any spa application. So I advice you to use oidc-client. It is a javascript library that is developed by the same guys who developed identity server. It makes the client very simple to develop when dealing with oauth authentication.
Here a more detailed description of the process and check/variable that are done/used:
The client application (javascript/html5) makes a call to the resource server without any token in the authentication http request header
The resource server (your api server) tries to get the token in the header
doesn't exists. This means the request is not authenticated.
The resource server return an 403 error to the client before even making any controller call or even authorization checks (roles and such)
The client catches this 403 error, and then knows that a token is necessary for this call.
The client stores the url of the request that failed and its post (if applicable) in the application db
The client redirects the browser to the authentication server url, by transmitting the client id (the identifier of the javascript/html5 application for the authentication server), the scope (what set of resource that should be used by this client application in the context of this authentication request) and the url where the authentication server should reidrect the user back once he is authenticated.
The authentication server asks the users to authenticate (in any way you can imagine, but most of time it is by asking him a login and a password)
if the user is recognized by the authentication server (password that matches the login), this one will check if the return url (the url that was transmitted by the client application for it to be used to redirect the user on the right page once he is authenticated) is in the list of granted return urls for this client application (the RedirectUris you are wondering about). The point of this is to ensure that the the issued token is not transmited to an ungranted application (like a external javascript/html5 application hosted in china that could find a way to suck some data from your api server that only your user can know about and submitting it to a russian api server without the user even noticing it)
it also checks if this client application (not the user... here it's to ensure that a specific client javascript/html5 application can access a set of resources) can use the scope that is requested.
if checks are ok, the authentication server issues an access_token by signing it with its private key.
the authentication server redirects the user on the initially transmitted return url, by setting the access_token in the url as a parameter.
the client application get this parameter and stores it somewhere (anywhere you want, but most of time in the application db and in memory)
the client application get the url that stored for the call to be done again, but with the access_token in the authentication header this time
the api server (or resource server) receives the http request again
finally find an access_token and checks if the it was actually issued by the authentication server (using its public key) since it is the only tiers that is trusted to issue a token.
then it can trusts what is in the token: the user id that is mentionned inside, scopes (set of features) that are allowed to be accessed, etc...
then it calls the controller and returns the response. If the token is expired, (a simple date that is in the token) it doesn't make any call to the controller and return a 403.
FYI, anything that is in the token can be trusted if its signature has been done by then authentication server. This system prevents the man in the middle security breach. Meaning: a guy who got a token by spying the network activity, changes what is inside this token so that he can make any call he want against your api server. Any changes that is made in this token will be detected because the signature (some sort of encrypted hash) won't match the new content anymore. And this signature, if everybody can check it in the world with the public key, only one tiers can issue it with its private key: the authentication server.
I tried to make it as complete as possible and yet still understandable for a newbie in oauth that you claim to be. Hope this helps.
We're in a scenario where a single page application that we develop ourselves (AngularJS front end with https server APIs in the back) opens another
web application developed by a partner of ours in a new browser tab, and where this second web application needs access to a https server API that is also developed by us.
After looking around for possible solutions, we have now created a proof of concept using IdentityServer4, where the second web application is configured as a client with "authorization_code" grant type. When all applications are running on the same domain, the third party application is able to access our https server API without being prompted for user id and password.
The implementation of the second web application in this proof of concept is very much like the solution presented by bayardw for the post
Identity Server 4 Authorization Code Flow example
My question now is:
When - in production - the second web application no longer shares domain with our application and our https server API, will a call from the second web application be prompted for username and password when accessing our http server API?
Seems, you are missing some major things. First of all any API should never ask for username and password. Instead your app(s) should put a token into each request and API should validate that token. Where the user credentials should be asked is when a user accesses your (or 3-rd party) web application. Then Identity Provider creates an Identity token (usually to be persisted in a cookie and used within the app) and access token (to be provided to APIs). Each token is issued for specific Client (app) pre-registered in IdP. Probably when been hosted at the same domain your two apps shared the identity cookie and Client Id what is not correct. In production scenario you have to register the apps separately. All the rest should work fine (if you follow the routine i briefly described at the beginning).
Chosing to post an answer myself from feedback through other channels:
This boils down to the session tracking of the IdP. If cookies are being used to track IdP session, the behavior is impacted by whether a session cookie or a persistent cookie is used.
In general, I have found that Robert Broeckelmann has great articles on medium.com.
In my current project i have following arcitecture
MVC application wrapping angularJS application (one action is provided to load templates for TemplateUrl in angularjs. Views are .cshtml instead of simple HTML pages which gives me flexibility to use Razor engine and do simple things like checking if users is in role and not render HTML template part.
second project is Web API project. once AngularJS application is loaded, it makes direct calls to API endpoint and uses MVC only for template loading.
MVC+AngularJS is hosted on -> subdomain.mydomain.com
WEB API is hosted on -> subdomain2.mydomain.com
currently app works without any issues, but i need to add authentication so the problem is;
how can i implement authentication flow in a way, that, If user is not authenticated it is redirected to the MVC login page,
Once it gets authenticated it gets authenticated in Web API as well.
If request is made to load template i can access authenticated user
roles.
if API call is made to API WEB API can check for authentication as
well?
how can i implement authentication flow in a way, that, If user is not authenticated it is redirected to the MVC login page,
You can do this by enabling Forms Authentication in you application. You can get number of documents online if you google that out.
Once it gets authenticated it gets authenticated in Web API as well.
WebApis are designed to be stateless. For authenticating there, use token based authentication where once user is authenticated, pass in a token with each webAPI request which can be validated at server before processing the request.
If request is made to load template i can access authenticated user roles.
Once user is authenticated you can cache user roles associated with the user's session and use that to identify his roles.
if API call is made to API WEB API can check for authentication as well?
Use Authentication token for this for identifying each request that will be sent from client.