I'm doing a simple project that consists of two separate parts:
Backend app in C# (ASP MVC) that server as business logic layer and
exposes public controlers/actions with JSON responses
Frontend app in PHP that serves as an interface to the backend app
I have implemented Forms authentication with custom MembershipProvider which stores user details in Entity Framework model and SQL Server.
The next step would be to enable OpenID authentication. What I need to do is:
In my frontend get user OpenID credentials (probably Facebook and
Google)
Forward those to my backend controler via POST request
Authenticate user with OpenID provider in my backend, storing their data (email only) in my model
Inform the frontend that user is authenticated
I've been going through different DotNetOpenAuth documents and samples, but I just can't figure out the point 3. in my list.
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 have created a Web API using ASP.NET Core 2.1 and it uses (successfully) JWT as a method of authorising requests.
The API is linked to a SQL Server database.
My users are stored in it using Identity as the base framework.
To authorise access for my API I take the username and password which is checked against the stored (Identity based) user.
Successful login returns an Access Token (with a 30min life).
Upon first logging in, a Refresh Token is generated and stored against the Identity user and sent back from the API.
All of this works well. My next step was to create a separate .NET Core 2.1 MVC site which consumes the API.
My question is:
From the MVC site point of view, how do I secure my controllers and views based on this security set up? I would normally use the [Authorize] attribute as part of Identity.
All I have on the MVC site side at the moment is the Access Token (and Refresh token) for the user in question.
I'm thinking the following solution:
MVC Site has it's own database and authentication for users (using Identity).
The connection (credentials/tokens) to the API is stored separately in the MVC site database and used as a 'global' way on the server-side to execute calls against the API
You should use an OpenID Connect and OAuth 2.0 framework. please check IdentityServer4. It also support asp.net core identity
IdentityServer is an OpenID Connect provider - it implements the
OpenID Connect and OAuth 2.0 protocols.
Different literature uses different terms for the same role - you
probably also find security token service, identity provider,
authorization server, IP-STS and more.
But they are in a nutshell all the same: a piece of software that
issues security tokens to clients.
IdentityServer has a number of jobs and features - including:
protect your resources
authenticate users using a local account store or via an external identity provider
provide session management and single sign-on
manage and authenticate clients
issue identity and access tokens to clients
validate tokens
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
What is the project and requirement?
I have clients - say around 200 - and they want that to implement social login on their website so that their users can login using social media accounts like Facebook and Twitter and others.
My clients don't want to be involved in complex flow of OAuth. I have offered them a service. My client will simply request to my service name "Social Connector" with post back URL (where I can post XML data back to them). I will fetch all data on user behalf and then convert it to XML document and send back using post back URL.
I have been able to successfully implement an ASP.NET MVC 5 web based client that will consume the API from different social media providers like Facebook, Twitter, Google+ using OAuth 2.0.
Consider the following things
I have to redirect user to autorization page where user can enter his credential
Then social media send code back to redirect URL
Get access token and then get user profile
Process data from social media and make an XML document(specific requirement by boss)
Post xml document and redirect user back using post back URL in same request(done by form post and auto form submit on body load)
Show error page in case of any error
But my boss says that we need to have a Web API based client that will do the same.
My questions are:
Is it good practice to use web API based client for social sites using Oath 2.0?
Should I continue with the ASP.NET MVC web based client?
Can I do this all using Web API client?
First, using OAuth2 to get a user's profile from social media services is a specific protocol named OIDC: OpenID Connect. It uses OAuth2 to let the user authorize your service to access profile informations from the social media. So, OIDC is an extension of OAuth2.
With OIDC, there are two roles:
the IDP (Identity Provider): has informations about user's profile
the RP (Relying Party): wants to get authorization from the user to access his profile from the IDP
So, your service is a relay:
from your customer point of view, you service acts as an IDP, with your own simple protocol (posting back an XML doc, instead of using some complex JSON web tokens like OIDC IDPs do)
from the social media point of view, you service acts as a RP
What you did is exactly what FranceConnect does: FranceConnect is a french public service, that acts as an IDP in front of its customers (french public services, for health insurance for instance) and a RP in front of french public identity providers (some public administrations, like the public department of finances).
Is it good practice to use web API based client for social sites using OAuth 2.0?
What you want to do can be done with your web mechanism (posting XML back to your customer) or with an API. Both can be done and both have been done:
FranceConnect is doing that only with web mechanism
KIF-IdP is another implementation of OIDC that acts as a relay like yours, but doing that with an API based on web services for instance.
So, your mechanism and what your boss asks you to do are both implemented. So, both can be done.
Should I continue with the ASP.NET MVC web based client?
You should look at some OIDC libraries, since it would be easier to do than using only the sub-protocol OAuth2.0 and implementing a specific way to get the profile with each social media server. Getting the profile is a standard method with OIDC, it does not depend on the social media.
Can I do this all using Web API client?
Yes. Both can be done.
What is the correct way to use IdentityServer3 and OpenID Connect (flow and configuration) in order to implement the following:
We have one MVC site Products and one Web API Products.API. We must secure all Web API endpoints:
Some endpoints can and should only be accessible by the MVC application on behalf of an authenticated (logged on) user.
Other endpoints, such as the ones used for account registration, password reset or anonymous operations, need to be authorized to the MVC client site directly, since there is no authenticated user in the picture.
We are currently using the Hybrid Flow, but this was mostly motivated after watching one of Dominick Baier videos. I've looked into https://gist.github.com/jawadatgithub/638c11f08ecc0d76b05c and it seems what we are looking is a combination of Client Credential Flow and Resource Owner Password Credential Flow, but I'm not sure I can even mix two flows as apparently it is not recommendable.
You could split the API into a "service" type API and a "user" API and have separate auth flows but do you really need to have the 2 APIs?
Does the registration code really belong in the API? It sounds like the the MVC app (guessing that it is also your identity provider) should deal with account registration - this is normally a key separation in using Oauth2.0 : the API doesn't concern itself at all with user admin!
If you do refactor the registration functionality to sit with the identity provider / Auth server, then do you still have the need to have 2 auth flows?
If you do, you could use just the password flow and have a fake "admin" user setup in your identity system for the non-user context endpoints. Your MVC app can pass in the credentials for the "admin" user and the API can code for this specific user. It's horrible, I don't recommend it, but I've seen it work!
I have an MVC application built that uses forms authentication and stores credentials encrypted in AspNetUsers
I also have a web api application that using that same store of users and is secured with oAuth.
The api is tested and works from an javascript app (going to be deployed on smartphones).
Now I also have a need to access the same API from the MVC app. Basically the user is already logged in an authenticated, but as far as I can see, in order to get an access token from the API (calling the api/token endpoint) I need the users password, which is one way encrypted in the DB.
The API and MVC app are deployed as two separate apps.
I guess one way I could do this is to grab the access_token when they first log into the MVC app and store it in the user table.
Is there a another recommended way to handle this in the .NET world?
Thanks