Background:
My Xamarin Forms application is calling Secured WEB API (built-in ASP.Net) to save data, while saving, I need to consume third party API to validate few fields. The third-party API is non secured (without HTTPS).
The Problem:
The issue is, my API call to secured API to save data crashes/doesn't complete.
R&D I tried:
I hosted ASP.Net Web API on my local server and tried accessing it via Postman (for some reason Xamarin app is not able to communicate with my local server). the call goes through without any problem including communicating with a third-party API to validate data.
Related
What I am trying to do is use WebAPI to authenticate both an MVC application and a mobile app using Token based auth. I currently have the MVC application authenticating with the database directly using the standard .NET SignInManager code the VS generates. I have my WebAPI in a different project and will reside in a different website.
I have the mobile app using the API for token based auth. What I am trying to do now is move the MVC app to use this same auth. I am hoping to using the SignInManager as I am now and just change the underlying auth location to the API using tokens. I am doing this to authenticate the user in the MVC application and also using the token from the API to secure the API.
I not sure that this is a good idea or what the best way to accomplish this is. It may be a bad idea. Maybe I should merge the API and MVC applications into the same project? Any feedback or ideas would be great.
If this does not make sense, please let me know.
The idea of a Web Api is the possibility to use a Service with multiple clients, i.e. an Angular Web App a Xamarin Mobile App and a Console App, all of them consuming the services of the API using the same Auth Method, usually Token based, conceptually that is the idea.
Now in your scenario you created a MVC Web App and then a Mobile App but for the mobile app you created also a Web Api, so basically you have two places where you put your Business Logic.
What I would recommend is to move and centralize everything in your Web Api and use that Auth only so in your MVC client project you just store your token as you do in your mobile App.
I have the following set up:
A web app (Jetty/Java)
A native client (iOS) (calling my webapp)
The Microsoft Graph API (called from my webapp)
The idea is that the user should sign in with OpenID/Oauth2 using his/her Office 365 credentials. The webapp will then call the Microsoft Graph API on behalf of the user (offline as well).
To achieve this I'm pretty sure I need to use the grant type: "Authorization code grant".
I can find a lot of example of the Oauth2 flow for browser based apps, and for when the native app calls the Graph API directly... but I want my backend to call the Graph API (and hold the access & refresh tokens).
So the question is how to do this properly? Here is my idea at this point.
From the native app: open a browser, call my web server which will trigger a redirect to the Azure /authorize endpoint (example: https://login.microsoftonline.com/[tenant]/oauth2/v2.0/authorize?client_id=[clientid]&response_type=code&scope=offline_access%20user.read%20calendars.readwrite&response_mode=query&state=12345&redirect_uri=my-scheme://oath2-code-reply
This will trigger authentication/authorization and then send the access code back to the app (using a custom scheme redirect: my-scheme://oath2-code-reply).
The app can then call my web app with this access code, where we can exchange the code for refresh & access code, and also create our own session for the user.
Is this the correct way?
Or should the entire flow occur in the browser and as the final step I open the app again with something like myapp-scheme://?sessionid=[our-own-session]?
For your scenario, you should use the on-behalf-of-flow.
A server-side sample that you can use as reference is https://github.com/Azure-Samples/active-directory-dotnet-webapi-onbehalfof - a note is that this sample is a .NET sample using a JavaScript SPA as a client - but hopefully it can guide you. You can use this sample for an overview on how to request tokens for your web api.
A note is that your item '1.' suggests that you are using the 'v2' endpoint. The 'v2' endpoint has some limitations, including for the scenario you are trying to accomplish (request access token to a Web API) - please see this document with information on these limitations, therefore my recommendation is to use the v1 endpoint at this moment for your scenarios -- which mean that you can only authenticate corporate accounts (and not MSA). The documents and samples I've indicated above uses the v1 endpoint.
Here is my situation:
There is a API service and it'll publish a new version once a season.
I create a web application for each version. So there's a list of web applications under default website that looks like:
API_2016S1
API_2016S2
API_2016S3
...
For clients, the url of API should be the same, even its version has been changed.
The version info won't be a part of the API url.
And the relationship between client and API version is storing in a database.
So the flow of a client's request may looks like:
client
send request(with client id in the header and session's cookie)
a portal application that do:
authentication
determine which API application should be
send client's request to specific API application
specific API application do:
receives request(regardless of authentication)
process request
response to portal application
the portal application responses to client
So for the upcoming new version of API service, I just need to create web applications for them and setting relationships in the database.
For now I'm trying to build the portal application by myself.
My question is: Is there any similar structure or mechanism can handle this kind situation? Or any idea for me. Thanks!
What you are looking for is called API Gateway or API Middleware. Instead of sending requests to the actual APIs, all clients send those requests to this middleware and it serves as a proxy and forwards the requests to a correct APIs.
There are some open source solutions such as KONG, Tyk (and others ) that you can deploy and manage by yourself or you can consider AWS API Gateway as a managed service.
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
I am using thinktecture identity server v3. I created web application and web api service. when I am accessing the web application, I got the access token from identity server. I used this token as bearer token to communicate with web api. Everything works fine.
But I noticed that at api server, for every request with access token, it automatically calls the identity server. If the idenity server is up, then it served otherwise it gives unauthorize error.
What is the purpose of this call?
What data it carries with the call?
If it is for validating the authority, it will more burden to the identity server.
Is it possible to skip this call?
You cannot avoid this:
when a user authenticates with the identity server, it creates a token which is given to the client to indetify itself. This token is created on the fly by the identity server, which remembers it
the client presents this token to your Web API server, which knows nothign about it, but knows who can validate it. So your Web API server communicates with the identity server so that it can get the identity back from the identity server
That's the reason why it works this way.
If you wanted to avoid this behavior you could map the identity from the external identity server to an identity controlled by your own web API server, and use an authentication method under your control to avoid querying the token from the external identity server. However, if you're using an identity server is precisely becasue you don't want to implement it by yourself, so this option makes no sense. This option is used when you want to map users from popular external identiy servers (like Google or Facebook) to users under your control.