Security and methods of implementation

I notice that OneMap API authentication uses JWTs to authenticate the user. Thus, I’d like to ask for opinions/best practices for storing these tokens.

2 main ways I see of using the tokens, and their pros and cons:

Server-side authentication - Every API call passes through your server
Pros: Fine-grained control of each API call from your users
Cons: Increased traffic through server

Client-side authentication - Client stores a copy of the JWT, and is attached directly to each API call
Pros: Less server traffic
Cons: JWT on client-side can be decoded for sensitive user information (i.e. user email)

Are there any hard and fast rules? Is one approach better than the other?

Thanks :slight_smile:

1 Like

Hi Edwin,

Personally, I will evaluate based on the use-cases of the application. If the app’s nature is non-sensitive, public-facing and you are expecting lots of users, you should direct your calls to the API providers.(We are built to handle these loads.) In many scenarios, mobile apps fall into this category.

Whereas for web applications, we generally preferred to do a server-side authentication due to security reasons. lol

For sharing: It is generally harder to obfuscate your code on a web app compared to a mobile app. People might just decide to misuse your token and trying a DDOS on OneMap. (Our initial response might be to temporarily suspend that account. We don’t want to affect your app negatively but it is a measure.)

Btw, you could choose implement both measures too.(Kiasu!!!) In case, your servers cannot handle the load, you can fallback on the client to work the magic.

Hopefully, this shades a bit of light for you. Im learning still. (If there are experts around, feel free to share :smiley:)

Regards,
Kai

1 Like

@kaicong Thanks for the insight!

I’m thinking that passing the JWT via the client is kinda like a security breach already, since someone snooping on the web traffic can obtain the token quite easily. Even so, it is my preferred method since I don’t need to maintain serverside API code :smile:

Will look into it abit more. I intend to integrate some other Gov APIs into my web app, so it might make sense for me to write my own APIs…

Hi Edwin,

JWT is stateless and is set to expire once every three days on OneMap. Hopefully, this lowered the chance of being abused. Anyways, nothing beats constantly monitoring of web-traffic for abnormalities. You can opt for tools like DStat, Grafana and etc. These are free and extremely friendly to use.

Sounds interesting! Is your web app rolled out to public? What’s it about?

Cheers!

Kai

Hi Edwin,

Sounds great. Your advice will also serve a good guide for users to practice setting good password!!

Btw, I shall omit 1 of your fields for safety purposes.

Regards,
Kai

– Deleted and Repost original post to omit some data –

@kaicong ATM, I’m working on a Google Maps rip-off, with the aim of using only the APIs from OneMap and LTA DataMall, and other Gov APIs, for fun. I’m also experimenting with Progressive Web Apps, so this one can be downloaded from the browser, and run like a native app (on Android, I dunno about iOS).It can be found at https://maps.crazy.technology.

More on the JWT thing

By design, the token can be decoded on the client to obtain information like issue timestamp, expiry date, etc… However, in this case, the token also contains unencrypted info about the user. From the Authentication Guide page, there’s an example token.

Running it through a decoder, such as the one found here produces:

{
  "sub": 653,
  "user_id": 653,
  "email": "your email",
  "forever": false,
  "iss": "http://om2.dfe.onemap.sg/api/v2/user/session",
  "iat": 1501832268,
  "exp": 1502264268,
  "nbf": 1501832268,
  "jti": "ee73b9d5a2060cf852ee6972b061bacd"
}

Since the API key holder’s info is there, the account could be more vulnerable to getting hacked. (It’s not a really big deal if you have good password practices, but I thought it’s good to know.)