The requirement to implement $subject is to enable client-side web applications (Javascript driven SPAs) to use OAuth2 APIs easily. When an SPA uses OAuth2 protected APIs, they are required to present a valid access token. To do this these Applications need to execute some Javascript on the client side (we browser) which reads an access token stored in some storage and adds it as a header to the request initiated from the SPA (browser).
The problem here is that if a token is to be stored in a way that is accessible by client side Javascript, the token becomes vulnerable to any type of Javascript that runs on the domain of the particular web application. Meaning that if the application becomes vulnerable to a cross site scripting attack (XSS) they run the risk of the token being stolen by an unintended party. To keep the token safe, it makes sense to store the token in 'httpOnly' format so that they become inaccessible to Javascript. This way, the token will be submitted to the API in a cookie and hence the need for the Gateway to identify the token which it may now receive in the form of a cookie and no longer as an HTTP header. Make sense. Thanks, Nuwan for the clarification. Regards, Ishara Cooray On Mon, Jan 14, 2019 at 11:29 PM Nuwan Dias <[email protected]> wrote: > The requirement to implement $subject is to enable client-side web > applications (Javascript driven SPAs) to use OAuth2 APIs easily. When an > SPA uses OAuth2 protected APIs, they are required to present a valid access > token. To do this these Applications need to execute some Javascript on the > client side (we browser) which reads an access token stored in some storage > and adds it as a header to the request initiated from the SPA (browser). > > The problem here is that if a token is to be stored in a way that is > accessible by client side Javascript, the token becomes vulnerable to any > type of Javascript that runs on the domain of the particular web > application. Meaning that if the application becomes vulnerable to a cross > site scripting attack (XSS) they run the risk of the token being stolen by > an unintended party. To keep the token safe, it makes sense to store the > token in 'httpOnly' format so that they become inaccessible to Javascript. > This way, the token will be submitted to the API in a cookie and hence the > need for the Gateway to identify the token which it may now receive in the > form of a cookie and no longer as an HTTP header. > > On Fri, Jan 4, 2019 at 5:04 PM Chamindu Udakara <[email protected]> wrote: > >> Hi All, >> >> My project is to add cookie based authentication for micro-gateway. This >> is the approach that I have come up with. Please review and let me know >> what you think and please be kind enough to suggest your suggestions. >> >> Requirement >> >> Provide authentication for product micro-gateway with cookie based >> authentication which uses session HTTP cookies for authentication. >> >> Suggested Approach >> >> When an user invoke an API with a cookie, micro-gateway has to validate >> that cookie prior to the response. The list of cookies included in the HTTP >> request which use to authenticate, have to be extracted from the request. >> From all extracted cookies,their respective session ID value has to be >> extracted properly. >> >> The Authn filter will check incoming request to micro-gateway and >> determine whether it contains header as "Authorization" or header as >> "Cookie". If header is equals to "Cookie" then the cookie validation >> process will be executed and cookie will be validated. If not it will >> execute as a normal request which contains header as "Authorization". The >> session ID of the required cookie can be provided to server as a direct key >> value pair at the micro-gateway server startup. >> >> >> >> >> >> >> if (request.hasHeader(authHeaderName)) { >> >> authHeader = request.getHeader(authHeaderName); >> >> }else if (request.hasHeader(COOKIE_HEADER)){ >> >> //Authentiction with HTTP cookies >> >> CookieBasedAuth cookieBasedAuth = new CookieBasedAuth (); >> >> result = cookieBasedAuth.processRequest(listener, >> request, context); >> >> }else { >> >> log:printError("No authorization header was provided"); >> >> setErrorMessageToFilterContext(context, >> API_AUTH_MISSING_CREDENTIALS); >> >> sendErrorResponse(listener, request, untaint context); >> >> return false; >> >> } >> >> Above code segment will do that identification of header type of the >> coming request. Then the validation process will be done at the separate >> file named as* "cookie.bal"*. In this file the extraction of session Id >> and validation of that Id with given value at the server startup will be >> done. For that I have implemented a new function as "*ProcessRequest*" >> which returns a string or an error. If any of the cookies included in >> request is not equal to given Id then the validation process will be >> failed. If it fails, then it throws an error and authnFilter will be >> failed. If any of session Id of a cookie matches with given one then that >> id will be returned to authnFilter for further execution at authnFilter. >> >> public function processRequest(http:Listener listener, http:Request >> request, http:FilterContext context) >> >> returns string|error { >> >> boolean isAuthorized; >> >> //get required cookie as config value >> >> string requiredCookie = config:getAsString(COOKIE_HEADER, default >> = ""); >> >> //extraxt cookies from the incoming request >> >> string authHead = request.getHeader(COOKIE_HEADER); >> >> string[] cookies = authHead.trim().split(";"); >> >> foreach cookie in cookies{ >> >> io:println(cookie); >> >> string[] sessionIds = cookie.trim().split("="); >> >> string sessionId = sessionIds[1]; >> >> if (sessionId == requiredCookie){ >> >> return sessionId; >> >> } >> >> } >> >> error notFound = {message:"No matched cookie found"}; >> >> return notFound; >> >> } >> >> >> >> *Chamindu Udakara * >> *Software engineering Intern* >> WSO2 (University of Moratuwa) >> *mobile *: *+94 755285531* | *email *: [email protected] >> > > > -- > *Nuwan Dias* | Director | WSO2 Inc. > (m) +94 777 775 729 | (e) [email protected] > [image: Signature.jpg] > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
