I've been following the technique outlined here:
http://blog.novanet.no/anti-forgery-tokens-using-mvc-web-api-and-angularjs/
The scenario:
I have an MVC4 application making AngularJS ajax calls a separate MVC4 WebApi application. These applications are completely separate and may eventually live on separate web servers.
What I'm seeing is that as the process goes, I can generate a token on the client (View), and then I can add a custom header attribute to be sent along with the ajax request. When the request hits the WebApi, I can see and parse out the token, but when I try to validate it, I get this message:
The provided anti-forgery token was meant for user "me", but the current user is "".
I'm thinking when I generate the token on the View, I'm building a token that relies on the currently authenticated user, and that's what get sent to the WebApi. So my question is this:
What is the standard way to lock down a WebApi when the WebApi is designed to be flexible to accept requests from a public website (anonymous access)? Do I need to build my own token mechanism that gets validated in the WebApi?
Thanks in advance!
Related
Hi I am exploring some of the authentication and authorization flows with respect to azure active directory. I was using previously oath implicit flow in single page application. After spending time in reading microsoft documentation, I have understood following with respect to implicit flow.
Implicit Flow:
Single page javacript application uses implicit flow to get obtain access token from azure active directory. It directly calls token endpoint to obtain the token so this makes implicit flow less secure.
Authorization Folw in .Net Web application
Whenever we use .Net core web mvc application with authorization code flow, first call will happen in browser to authorization endpoint to get code. In browser we could see the request made to authorization end point. In request url I will pass response type as code then client id and redirect ui. Here first handshake take place between browser and authorization end point. This handshake returns code to the redirect uri. Next part, application has to make POST request to token endpoint to get access token. Code received in first step I will send in token request. In this request I will include client secrete also, redierct uri also. But whenever I make first GET request to authorization endpoint I will not pass client secrete. This is because Its not good to expose secrete in browser. So in second post request I will include client secrete also. Once I get access token I will add it in api request header to make secured call to apis.
This is the authorization code flow flavor I have understood with respect to .Net core web application. now I have another flavor of authorization code with respect to single page application.
Authorization Code Flow in React Web App
I have SPA react application which uses MSAL library. I have cloned sample application from github https://github.com/Azure-Samples/ms-identity-javascript-react-tutorial/tree/main/3-Authorization-II/1-call-api/SPA.
Whenever I run this application, and sign in first call will happen as below
https://login.microsoftonline.com/common/discovery/instance?api-version=1.1&authorization_endpoint=https://login.microsoftonline.com/c5ffa990-7e0a-4bf6-6c04-79ab98e05931/oauth2/v2.0/authorize
I am trying to understand this request. I have query string appended to the url authorization_endpoint=https://login.microsoftonline.com/c5ffa990-7e0a-4bf6-6c04-79ab98e05931/oauth2/v2.0/authorize so this may be used to return the code from authorization server.
Immediately next call will happen https://login.microsoftonline.com/c5ffa990-7e0a-4bf6-6c04-79ab98e05931/oauth2/v2.0/token
to get access token and in request in FormData section I could see following parameters
client_d, redirect_uri,scope,code
In code I see some code value hopefully received from authorization endpoint. anyway this api returned me access_token.
Now coming to conclusion, In .Net core web application and React SPA application both places I am using authorization code flow.
In .Net core authorization code flow I am making use of client secrete whenever trying to obtain access token. All this happen in server side in secure manner. In react also I am using Authorization code flow but I am not using Client secrete anywhere.
In react app also I am making two requests one for authorization endpoint to get code and another to get token. All this I can see in browser itself but then How can I consider this is as secure?
In .Net web app and react app both apps making use of authorization code flow but it behaves independently depends on the type of application.
After going through several documents and videos over the internet I concluded myself as
When Authorization code flow used with server side web apps like .Net core MVC, It makes use of client_secrete to get access token and this call will happen in server side so client secrete not exposed through browser to the users
When Authorization flow used SPA applications without server side support, first it will make call to get authorization code then It will make post request to get access token WITHOUT client_secrete.The only way the authorization code grant with no client secret can be secure is by using the “state” parameter and restricting the redirect URL to trusted clients.
So I am concluding myself as when we use server side web app with authorization code flow we can make use of client secrete but in case of SPA we are not making use of client_secrete.
I have understood above concepts and explained what I understood and also I listed the confusions I got after implementing 2 flavors of authorization code flow in web app and spa app. can someone help me If my understanding is correct or not, If my understanding is wrong, where exactly I understood wrong? Can anyone help me with respect to this. Any help would be greatly appreciated. Thanks
Authcode flow is an OAuth 2.0 workflow, you can use it in any kind of client (Web/mobile/SPA).
Clients should be using MSAL library to communicate with AAD/B2C with PKCE which is used to secure authorization code grants via Proof Key for Code Exchange (code_challenge) with S256 encryption.
Authcode Grant Flow spec:
If you are using B2C, your entry endpoint is:
https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&response_type=code
&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob
&response_mode=query
&scope=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6%20offline_access
&state=arbitrary_data_you_can_receive_in_the_response
&code_challenge=YTFjNjI1OWYzMzA3MTI4ZDY2Njg5M2RkNmVjNDE5YmEyZGRhOGYyM2IzNjdmZWFhMTQ1ODg3NDcxY2Nl
&code_challenge_method=S256
that will display the SignIn-SignUp-Social Login Form. Just navigate to this URL with you App ClientId registered inside B2C.
You also can take a look to the custom policies starter pack to adapt your workflow to your needs (claims).
If you change response_type=code for response_type=id_token you will get a Token that can be used to authenticate against your restricted resources (API's) after all login process.
Or you can use a second call to the token endpoint to get it.
Token endpoint:
POST https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6&scope=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...&redirect_uri=urn:ietf:wg:oauth:2.0:oob&code_verifier=ThisIsntRandomButItNeedsToBe43CharactersLong
code=XXXXXXXXXXXXX parameter is the access_code returned from first GET request.
Solutions to this is to switch to implicit flow, where there is no need of exchanging code for access token. But keeping access token in web application still vulnerable as this can be exposed using XSS or similar kind of attacks.
Other best practice is https://curity.io/resources/learn/the-token-handler-pattern/
I know there are tons of examples for Token authentication and OAUTH, but I haven't been able to make sense of any for my needs.
I have created an AngularJS/Web API application that displays data from a database in some forms using Web API calls. Our company has an authentication portal, that once you have logged in, if you have access to the application, it will redirect to the application URL with additional data such as token, login_id, etc. I don't plan to have a registration or login page in my application at all. I simply want to use the redirect URL to authenticate the user with the token provided. I will need to make some additional calls to see about additional rights.
The user is redirected to my URL with the additional parameters in this form:
https://myserver.com/?data=AOSTOKEN_1_5:XXXXXXXXX&logonId=XXXXX&badAttempts=0&passwordExpireMs=1517223840000&version=1&changePassword=false&country=US&css=&js=&language=en&limited=null&x=31&y=4&staticId=123456789&faceStaticId=null
My intuition is that I need to make a route (I'm using MVC System.Web.Routing to handle route management) for my Web API to handle this data, but I don't know how that will work with the AngularJS view. The closest example I can find is from here, but I won't be using a database or anything. I know this is a vague question, but any help will be great!
I was able to do some quasi authentication using the HomeController.cs file of my MVC application. I can parse the query string data in the main method (or any of the other view's methods) by adding some parameters.
For this instance, I modified my Index method to the following:
public ActionResult Index(string data, string logonID, string badAttempts, string passwordExpireMs, string staticId, string faceStaticId, string version)
{
//Handle null data, validate token data, and redirect if unauthorized.
}
I have bought an API that can be used in a mobile application. API includes the Key and username as expected.
Within the app, this API needs to be called on Payment confirmation.
I found that using tools like Fiddler, one can see the request made by the application. If that is the case, it is just a matter of seconds to fully get access to the API signature.
It would be of great help if someone can help out/add to this issue.
My thoughts:
Use a server to make this API call instead of calling it directly
from the application.
If a server is used, the issue would still exist as the API call made to the server(eventually which calls the bought API) can also be interrupted/accessed
How to secure the call made to the server from the application?
Technologies: Angular JS, Node JS, Ionic framework
Look at my answer to this question. Instead of using the user name and password, your backend could provide an additional resource that allows the user to create a token with a special scope.
In your AngularJS application you can use the $http or $resource services (if the ngResource module is included) and obtain such kind of token that allows you to access only the parts of your backend your client really needs.
This token must be cached at the client side and included in the header of each request.
In AngularJS storing the token in the header of each request can be done at a central place if you are using the config function of the module you created.
app.config(function($httpProvider) { $httpProvider.defaults.xsrfCookieName = "TOKEN" }
AngularJS also provides some additional security features. For example you could use the JSON vulnerability protection mechanism. If you are using this, your backend had to add the characters )]}', (you could also override the default characters) to each JSON response body.
For other clients the JSON response will be invalid Javascript code, but in your AngularJS application the characters will be automatically removed.
UPDATE
The best way for implementing security for your application would be reading and understanding the OAuth2 specification.
In this video from minute 11:36 to 17:26 the JavaScript flow is described.
This site provides some implementation of the standard for different programming languages.
Some of the aspects in this standard are that all clients and redirect urls must be registered in an additional authentication server. Client are identified by a unique client id.
To avoid that some other application intercepts your requests for extracting the token, the original token should only be active for a small amount of time and each api request must be SSL encrypted.
For providing Single sign-on also refresh tokens can be used.
I'm trying to understand how an saml authentication flow could work in a mobile environment where the client (AngularJS based), api server (Node & passport based), and idp exist on different domains.
From what I've gathered the general practice is to have the server return a 401 to the client if there's no authentication present (i.e. the client didn't include a bearer token in the request). The client understands that a 401 response indicates to open up the login endpoint on the server. When the login endpoint is opened it makes a passport call to the auth provider (which redirects the user to the auth provider's site) and supplies a callback URL. When the user authenticates, the auth provider redirects to the provided callback URL, which allows the server to retrieve information from the auth provider's response and construct a token of some sort (e.g. JWT) that can be used by the client (i.e. included in the headers) when making REST calls to identify itself.
My question is: How does the client get the token from the server? Because we're in a redirect-based authentication flow, I can't just return token from the callback function; that would just display the token in the browser without handing it off of to the client. Does the server just issue a 302 redirect pointing back to the client domain and include the authentication token in a header? Maybe I should not redirect from the client to the server in the first place and instead window.open() and use window.opener.postMessage or is that too old fashioned/mobile-unfriendly?
This question talks about authentication against a SAML IDP, but I'm interested in getting more details specifically about that last bullet point and how it would work with an AngularJS-based client.
Many examples I've seen online are either a single domain using OAuth/SAML (passport-saml-example), which avoids the issue of having the client exist on a separate domain, or use two domains with basic authentication, which avoids the issue of redirecting to some third party for authentication, but I'm having trouble finding good examples that uses all the bits and pieces I'm trying to work with.
This blog post seems very close to what I'm trying to accomplish (see googleSignInCallback) and uses a 302 redirect like I imagined but that solution relies on explicitly knowing the client URL to redirect to, which seems like it could be problematic if I wanted to support multiple client types (i.e. Native applications) in the future.
Eventually I was able to work together a solution by having my application open a browser window (Cordova's InAppBrowser) to a SAML-enabled application, have that application complete the normal SAML flow, and then that SAML-enabled application generated a JWT. My mobile application was then able to extract the JWT string from the browser window with the InAppBrowser's executeScript functionality. Then I could pass that JWT string along to my API server, which was able to validate the JWT is properly signed and trusted.
After I implemented my solution I saw that there was similar functionality available on github:
https://github.com/feedhenry-templates/saml-service
https://github.com/feedhenry-templates/saml-cloud-app
https://github.com/feedhenry-templates/saml-cordova-app
Hopefully this helps anyone else trying to deal with this issue!
I have an AngularJS application (using ASP.NET Web API as the backend) that does not require the user to authenticate (the application has no login). I want to make sure that the REST API methods the AngularJS application invokes can only be invoked from the application. I obviously cannot use token based authentication for that.
If doing nothing special the REST API methods can be invoked freely using the browsers address bar or by writing a desktop application that invokes them. The same-origin policy is only regarded if a browser invokes an API method by a HTML page coming from a site having another origin. The REST API is therefore open to the public and easily hackable.
I wonder what I could do to securely restrict the access to the REST API. Any ideas or experience?
Edit 1:
I found an easy solution for my problem: I just check if the host of the URL referrer is the same as the host of the requested URL. Using ASP.NET Web API the code the REST API actions use is:
private bool ApiCallIsAllowed()
{
var request = HttpContext.Current.Request;
return (request.UrlReferrer != null &&
request.UrlReferrer.Host == request.Url.Host);
}
I am just not 100% sure if I always get the URL referrer.
Edit 2: According to this question the URL referrer ist not reliable. Bummer.
use ssh - that's obvious :)
login process should generate token - write it as a cooke - every http request will use it in header
prepare rest interceptor that will read your token and authorize every request
use some Javascript Obfuscator
Don't forget to invalidate session ;).
you can use spring-security or other framework to simplify this process