1

TL;DR How does CanActivate work?

Long version It is the first time that I see the implementation of a client-side access control.

In all the authentication systems that I used so far (e.g. PHP or other server side programming language), there's always been a function that checks if the user is already logged in, if such function returns true the server can deliver the page, otherwise the user get redirected to a login page.

In this case the client can't access the server code, it can only makes requests and wait until the server composes the page, then render it.

Instead, Angular works differently. It is a client-side framework which uses JavaScript, and its code is visible by everyone. The private page isn't securely placed inside the server, the only server task is to deliver the SPA, but it can't accept further requests.

Despite it, the framework implements features as CanActivate, and it works well. So I was wondering about what forbids me to inject some JavaScript code and access a private page, even if I don't have the right, or more generally how this system works. On the Internet I didn't find enough information and I don't have enough skills to understand the source code. Can you help me to clarify my ideas?

I could just ask the question in the title, but I preferred to tell you everything I know, so if there's something wrong you can correct me. Thank you

Christian Vincenzo Traina
  • 9,546
  • 2
  • 40
  • 63
  • You still need server-side authentication (since malicious user can access anything anyway). The protection methods router offers are kinda convenience for you. You should deliver empty templates without hardcoded secret data, and populate them for authorized user. Instead of doing permission checks on every component/page, `CanActivate` allows you do keep this in one place and reuse it. Check [docs](https://angular.io/docs/ts/latest/guide/router.html#!#guards) for more information and examples – Sasxa Apr 02 '17 at 15:52

1 Answers1

1

CanActivate does not Guard against stupid and/or insecure programming

TL;DR Even in SPAs sensitive data is protected by servers and is returned only if correct authentication token is passed along with the request. Wrappers or decorators like CanActivate, only make it convenient to manage the views, which without real data are just empty shells!

Long Version

Your question is not CanActivate specific but about concept of client side authentication IMO. You are correct in assuming that if any sensitive data has been pushed to SPA that should not be without proper authentication, then it can be accessed, with or without client authentication. However that is not the point of client side authentication.

Way CanActivate decorator or any other JavaScript/Mobile Token authentication system works is, it makes a authentication request to server, and server returns the authentication token.

Now SPA in its subsequent requests is expected to pass along that auth-token back to the server, and it is in these requests that server sends back real data if the authentication token is valid.

The SPA now takes this data and compiles it into a view for user. So, while SPA is conceptually a application all in the browser, it should (and does in sane cases) depend on sensitive data from the server which is authentication protected.

For folks coming from more traditional session based authentication systems this concept should not be very different. In case of sessions, authentication cookies are sent with sub-sequent requests, in case of SAPs Tokens are sent back. When it comes to authentication, that's the only difference.

As for the data returned, for SPAs, servers typically only return data and for classic server side application, servers compiles view + data and returns it.

Hope that makes sense and helps!

Shaunak
  • 17,377
  • 5
  • 53
  • 84