I've implemented the new LinkedIn JavaScript API to log in, and I'm trying to access a cookie. I've verified that it can be found in FireBug's Cookie window:
linkedin_oauth_*API_KEY*
where API_KEY is my API string.However, when I try to access the cookie in ASP.NET MVC code:
HttpCookie c = HttpContext.Current.Request.Cookies[cookieName];
It can't find any cookie with that name in the Cookies collection.
In FireBug, I see the cookie's properties are Expires=Session and Security=Secure
Is there a way to access cookies with these settings?
Problem is that the same origin policy applies also for the cookies, so your server backend doesn't receive the cookie.
I guess you want to sign-in with LinkedIn Js api, pass the oauth token to the server, and then make normal oauth calls on the server side? For this scenario, you need to send the oauth token back to the server. There is nice article describing this scenario: Exchange JSAPI Tokens for REST API OAuth Tokens
You can only access those cookie through HTTPS
Related
I have an ASP.net MVC web application that uses Microsoft's Owin middleware (Microsoft.Owin.Security.OpenIdConnect) to configure OpenID Connect authentication. My identity provider (Okta) is configured to support refresh tokens and I have confirmed that it is working. When signing in, my application receives an Access, ID and Refresh Token as expected. These tokens are validated and returned to the client in a cookie called ".AspNet.Cookies" (the default). On each request, the cookie and these tokens are parsed into a set of claims. Great so far. 👍
The Owin (Katana) middleware does not appear to do anything further with the Refresh Token, so I have implemented a token client to request a new Access Token from my IdP using the Refresh Token. This is working as expected. 👍
Two questions:
When and where should the application check to see if the Access Token is expired and request a new one?
After receiving new a access, id, and refresh token, how and where should the application update the user identity, claims and cookie?
OWIN COOKIE UPDATES
I believe the comment at the end of this post has the type of code you can write - I remember using similar code a few years back.
With OWIN you are using a server side stack secured by cookies so I'm not sure where access tokens are actually used, but maybe one of these is true?
The C# back end uses tokens to call an API
The Web UI downloads tokens from the web back end and makes Ajax calls to an API
PATTERN FOR HANDLING EXPIRED TOKENS
The only reliable pattern to handle expiry is to do this in the API client code:
When you get a 401 response from the API
Try to refresh the token and retry the API call with a new access token
If you can't refresh the token, redirect the user to sign in again
I always implement this with 2 classes, as in this SPA code of mine:
ApiClient - handles API calls
Authenticator - handles OAuth calls
If the Web UI is getting tokens from the web back end and then calling an API, your web back end could provide MVC operations similar to those in my authenticator class:
getAccessToken - get the current access token, though it may fail with a 401
refreshAccessToken - use this if a 401 is received and you need a new token
TOKEN EXPIRY TIMES
It is also possible to check token expiry times in the background - to reduce the number of client 401s. This is not a full solution however, since 401s can occur for other reasons in addition to expiry.
I am building an Angular SPA app and using Okta as an Idp. since its an SPA so I think I need to use Implicit flow. I have two queries here-
Since in Implicit flow a refresh token is not issued, does it means that th user will be logged out of the app after the token expires and he has to log in again?
Why do I need to use Implicit flow in case of SPA? why not Authorization code flow? since I have control over both the front end (SPA) and back end (REST API) . for example in case of Spring MVC architecture for the web app Authorization code flow is possible.
Thanks,
pchh
Yes, if the token expired, you have to re-autenticate. Normally you still have a valid session on the identity providers site, so you can do a "silent" login using an iframe. Libraries like oidc-client support a silent login, which can do this for you.
You need to use implicit (or hybrid) flow, when you need to access to the access token from your javascript app. With authorization code flow your javascript app doesn't get the access token, so if your API needs an access token for authorization, what are you going to send?
If your auth server supports OpenID Connect (OAuth2 extension) and single sign-on (SSO) feature, to get a new token before the old gets expired, use an iframe with a URL you used for authentication, but add prompt=none parameter (and possibly id_token_hint parameter). See OpenId Connect RFC. The prompt=none parameter tells the /auth endpoint to issue a new token(s) if the user has an open SSO session at your OAuth2 server. If not, the request will fail. There is a separate RFC for session management.
The Authorization code flow requires you to access the /token endpoint, which usually requires authentication (client ID + client secret) and you cannot keep the secret safe in a browser. For this reason, the token endpoint doesn't use to support CORS headers, so you cannot access it using XHR. Using the Auth code flow, you get a code as a redirect URL param (?code=), which gets to the server hosting your SPA (browser sends it there after redirect). The implicit flow returns tokens in hash part of the redirect URL (#access_token=), which stays in a browser (it's not sent to the server), so it's safer.
I am developing an app for salesforce. For authentication I am using the web server flow.
In salesforce OAuth implementation the session id is the same as access token. When I get the new access token (through refresh token method), what's the proper method to pass it to the client. Should I explicitly set the session ID to the new access token?
Assuming you included the web or full scopes when requesting the OAuth 2.0 access token then it can be used interchangeably with a Session Id.
You put the access token into a sid cookie are redirect to the correct instance/pod.
Better yet, you can use the frontdoor.jsp to setup the required cookies. See Using frontdoor.jsp to login to Salesforce UI and Communities
The client can handle this by having some logic for handling a request to the Salesforce API which fails with an Unauthorized response. When an Unauthorized response is received the client can ask your web server for a new access token / session id.
Alternatively you'd have to use WebSockets or some push technology to push the new access token to the client when the web server refreshes the token.
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
I have a rest API made with Grails, I can use spring security via Ajax auth, and store the jsessionid cookie in the client, but when i login with 'j_spring_security_facebook_json?access_token=' it doesn´t create the jsessionid cookie... and i can´t store the session in the client.
Does exist any solution for this problem? thanks.
As you're using an external client (mobile app), in most cases you have to use something different for authenticating your requests. Not a cookie. Usually it's OAuth2 or just a custom signature based on a shared key.
j_spring_security_facebook_json auth is supposed to be used as an exchange point, where server can pass a key/token for mobile client that have valid fb token. Then this token could be used for authentication of following requests.
See "How to extend JSON response" at http://splix.github.io/grails-spring-security-facebook/guide/3%20Usage.html#3.5%20Json%20Authentication